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

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

On Tue Dec 14 2010 at 09:27:10 -0500, Thor Lancelot Simon wrote:
> 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.

It doesn't but we/I didn't know then.  It was an experiment.

Not that it didn't work *at all*, it just doesn't work for this
particular purpose.

Since you're interested, another problem with it was "tagging" programs
at runtime, since our system call switch code relies on probing the
binary, not the environment.  This is something someone who wants to
finish usermode NetBSD should think about (should they not choose to
use ptrace()).

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

David's rework added the calls you think are not "an example of code
that is clear and easy to understand".  He didn't start from an ideal
situation, and neither did I.  The good news is that you seem to think
a little added "ugliness" made for a better whole.

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