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

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

On Tue Dec 14 2010 at 10:09:53 -0500, Thor Lancelot Simon wrote:
> I understand that you're a member of core and therefore, in effect, can
> pretty much do whatever you want to in the source tree with little or
> no oversight (and I do not actually object to the effects of this most of

Let's keep the facts straight.  I am doing this as an individual developer
and there is absolutely no blessing from core.  I personally believe
that a subjective "ugly" metric or problems which current experiences
suggest to be nonexistent are no grounds for objecting to anything which
adds functionality.  But if it comes down to it, six other members of
core may not agree with me.

> the time) but, honestly, you should be willing to explain and justify what
> you're doing, rather than just attacking people who, on the basis of their
> inferior knowledge, disagree.

I did answer your question the very first time you asked it.  I'll repeat:
It is not possible for a shim to know which way to go when given two
exactly identical calls because that knowledge is in the caller only.
If you don't believe me, fine, prove me wrong (preferably with working
code), but stop falsely claiming I'm not justifying things.

> Obviously I do not know some very basic things about rump.  Can you
> please back up and explain, from the 10,000 foot level, what problem
> you're trying to solve, how it fits into the architecture of rump as a
> whole, and why the solution you've chosen is not just the best one but
> (which you seem to be saying) the only one?

I'd love to.  To establish some common ground, can you familiarize
yourself with the material I've written, starting from

http://www.netbsd.org/docs/rump/

But since there's a lot of text linked from there, in short rump fills
a void in componentization, virtualization and flexibility that no other
OS offers.

This particular exercise with the clients makes the userspace port
much much much more accessible to people such as yourself who toy
around with kernel code all the time.  To get a good idea, compare
src/tests/icmp/t_ping.c::simpleping (read the test-specific library code
too) and t_ping2.sh::basic.

As another example, it's now possible to write a shell script which does
cgd-en/decryption without requiring root privs or cgd in the kernel
(again, see a test, now in tests/dev/cgd).  Roland had an idea that
this could be used to create encrypted installation images as part of
the build tools.  Yes, we're not there yet, but that might be something
to look forward to.

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