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

[Matt Thomas <matt%3am-software.com@localhost>]

On Dec 14, 2010, at 12:24 PM, David Holland wrote:

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

To me, this could be done with a special libc that redirects all syscalls
through rump.  I think the problem is having a program live in both worlds.

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

exactly.

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

And will never work correctly.

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

Agree wholeheartedly.