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

[David Young <dyoung%pobox.com@localhost>]

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.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933