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

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, Dec 14, 2010 at 03:37:26PM +0200, Antti Kantee wrote:
> On Tue Dec 14 2010 at 08:31:15 -0500, Thor Lancelot Simon wrote:
> > On Tue, Dec 14, 2010 at 03:24:49PM +0200, Antti Kantee wrote:
> > > On Tue Dec 14 2010 at 08:13:44 -0500, Thor Lancelot Simon wrote:
> > > > > 
> > > > > Yes.  It's not really a very difficult rule.  I can understand the "I
> > > > > forgot" vector, though.  I seriously doubt it'll be a problem, but 
> > > > > just
> > > > > in case, see below.
> > > > 
> > > > I have to say, this is extraordinarily ugly.  Why can't you make a rump
> > > > libc instead that shims these symbols?
> > > 
> > > Well I could, but since it doesn't work, I won't.  For example, how does
> > > a shim know what to call when it gets socket(PF_INET, SOCK_DGRAM, 0)?
> > 
> > It is impossible to determine at runtime which calls should go to the host
> > kernel and which calls should go to rump?
> 
> Are you serious?  Why do we need to write programs at all?

If that's not a non-answer-answer, I don't know what is.  And I don't think
I deserved a non-answer-answer, nor to have my concern otherwise dismissed
out-of-hand.

It may be obvious to you that some level of disruption to the rest of the
system is justified to make rump work better in some way, but less obvious
to other people.  If, for some bizarre reason, you needed to turn the
source code of every program in the system backwards, that would clearly
be too much, right?  Well, somewhere between there and no-changes-at-all,
there has to be a compromise.

I was trying to offer a helpful suggestion.  I don't think a snarky
response was appropriate.

To me, tearing through the source tree turning normal Unix system calls
that naive programmers can understand without knowing how rump works into
these bifurcated rump_syscall()/host_syscall() things is very confusing
and inelegant.  It makes it much harder to read the source code without
extensive background knowledge specifically about NetBSD and understand
what it does.  Wherever possible, we should try to make it so reasonably
competent Unix/C programmers without extensive NetBSD background can read
the code and get a good idea what's going on -- not the opposite.

So such changes should require very substantial public justification,
even more so because you're a member of core and should be setting an
example for others.  If I missed such an explanation and discussion,
and that's why you're snarking at me, I apologize, but I cannot find
one in my archive of tech-kern and tech-userlevel, which goes back
several months, so I do not think I did.

Thor