tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Rumpification (was Re: CVS commit: src/usr.sbin/envstat)

On Wed, Dec 15, 2010 at 03:18:06AM +0200, Antti Kantee wrote:
> On Tue Dec 14 2010 at 18:38:53 -0600, David Young wrote:
> > Looks like interesting and exciting work you're doing.
> How about you give it a spin if it's interesting ?)
> You don't even need to write/compile anything anymore, just run stuff.
> > I understand how avoiding prog_socket(), prog_open(), and other
> > "descriptor-creating" routines will be difficult or impossible, however,
> > I don't see why the rest---ioctl(), close(), dup2(), read()---cannot
> > be handled by syscall shims that refer to a table of extant RUMP
> > descriptors to see whether to make an ordinary syscall or a RUMP
> > syscall.
> Yes, that is most likely possible.  The plus side is that it reduces
> errors when using objects and the minus side is that it hinders
> readability.  We can certainly keep that technique under the belt in
> case there are problems that would be trivially solved by using it.

How does it hinder readability?

> > Do you think that ifconfig can configure itself for RUMP/non-RUMP
> > syscalls at run time by switching on, say, argv[0]?
> Assuming the program has been correctly codified, yes.  But it's more work
> for me and the 'puter.  For example, we'd have to rely on dlopen()+dlsym()
> for the rump stubs unless we want to require rump syscall client stub
> linkage to the one true ifconfig binary (which I think is a bad idea).
> What's the benefit you seek?

I thought that it might be nice if we could have one in the tree and
direct it to different backends with a command-line option: rump kernel,
host kernel, and whatever we may think up in the future.  It's not even
a fully-formed thought, yet.


David Young             OJC Technologies      Urbana, IL * (217) 278-3933

Home | Main Index | Thread Index | Old Index