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

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

On Tue, Dec 14, 2010 at 04:09:29PM +0200, Antti Kantee wrote:
> 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.

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.

If it is, in fact, impossible, how could a system call server work?  I don't
know, so please, rather than mocking me, it would be helpful if you'd answer
the 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()?

Do you really mean to suggest that the ifconfig sources are an example
of code that is clear and easy to understand?  Even after David Young's
rework, I would personally suggest that ifconfig is one of the worst
programs in the whole system in that regard.

The basic problem with ifconfig is that it uses a wide array of very
old kernel services, implemented via ioctl, which were not so much
designed as accreted.  If the relevant kernel services were replaced
with something carefully designed and sane ifconfig would not be so
ugly.  Which is not to say anyone should run out and rewrite ifconfig
and all the network ioctls, but it *is* to say they are not a good model
for new code.

I would like to see less code like ifconfig in the tree -- where possible --
certainly not more.

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

Perhaps a more reasonable conclusion would be that when the scheme exists
only in two or three programs, the likelihood of any particular person
noticing it and objecting is much lower than when it suddenly appears in
ten times as many!

I really think this deserves a detailed rationale now, not a reference
back to a discussion two years ago that I at least still can't find.  In
my opinion it really is very ugly, and if there is simply no other way
to do what rump wants, I would like to be led to agree with that rather
than just made fun of for asking for an explanation.

Thor