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

[Antti Kantee <pooka%netbsd.org@localhost>]

On Tue Dec 14 2010 at 08:52:00 -0500, Thor Lancelot Simon wrote:
> 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.

I was responding to your non-answer to my question.

If you want another simple example, why does ifconfig(8) use the "ugly"
calls to direct_ioctl() and indirect_ioctl()?  Why can't those calls be
replaced with just ioctl()?

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

The subject was discussed in 2008(?) on tech-kern in a thread about
syscall routing.  The only other suggestion involved a system call server.
That is not an acceptable solution for multiple reasons, the simple
ones being that it requires host kernel support and root privileges.
(I did implement one, but it was quite klunky, so I ditched that project).

The same scheme has also been used for over a year in the source tree
(see cvs history of e.g. cgdconfig and lfs_clearned) and nobody has even
once shrieked out in terror.  This leads me to believe it's a perfectly
acceptable solution for a slightly larger scale (where "larger scale"
is 20-30 utils instead of 2-3).

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