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

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Dec 14, 2010 at 09:27:10AM -0500, Thor Lancelot Simon wrote:
 > Perhaps the answer to the question of whether it's impossible to determine
 > at runtime which system calls should go where is more obvious to you than
 > it is to me.  I have not spent years immersed in the details of how rump
 > works, after all.  I strongly suspect other people (including other NetBSD
 > developers) are in a situation more like the one I'm in than the one you're
 > in, as far as that goes.

Since I think I understand the problem and pooka seems unwilling(*)
to explain, let me try:

The goal of these rumpified programs is to run on the host kernel but
operate on the/a rump kernel; that is, you run ifconfig at your shell
prompt and instead of configuring the interfaces of the kernel you're
running on, it configures interfaces of some rump kernel somewhere.

This means that the knowledge of which operations have to be sent to
the rump kernel can be placed only in ifconfig, because only ifconfig
knows which operations need to be local and which are supposed to be
proxied across to the rump kernel and affect the rump kernel instead
of the local kernel.

Well and good; it's true (AFAICT), what pooka's trying to do can't be
done less intrusively. The problem is that what he's trying to do is
the wrong thing.

If what you want is to configure interfaces on the rump kernel, then
the right way is to ifconfig (all of ifconfig) on the rump kernel.
This does not require modifying ifconfig, avoids all the problems that
have been cited in this thread, and is semantically far cleaner. All
it requires is an LD_PRELOAD hack or similar to intercept syscalls, so
the ifconfig process runs on the rump kernel, and the rump equivalent
of 'ssh rumpkernel $COMMAND' to bring back the ifconfig process's
output.

Writing programs that run half on one kernel and half on another is
gross. There is no way around that, except maybe to redesign the
syscall API from scratch.

IMO, all these changes ought to be reverted, including the earlier one
to dd and any others that have been lurking in the tree for longer.

-- 
David A. Holland
dholland%netbsd.org@localhost