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

[Antti Kantee <pooka%cs.hut.fi@localhost>]

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.

Anecdotally, a few years back I was jokingly grumbling to someone it
being a mistake that not every unix syscall takes an object identifier,
and I got "I'll tell Ken the next time I see him" back ;)

> 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?

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa