Re: CVS commit: src

[David Holland <dholland-sourcechanges%netbsd.org@localhost>]

On Wed, Dec 21, 2011 at 04:47:49PM +0100, Reinoud Zandijk wrote:
 > Hi folks,
 > 
 > i am not subscribed to this mailing list so i only found this
 > discussion when someone pointed it out to me.

Realistically, you should always be subscribed to either
source-changes or source-changes-full, or source-changes-d, at least 
if you're committing anything.

Let's move this to tech-kern where it belongs, though.

 > The code was indeed committed a bit short-tracked and i'm sorry for
 > that. It just happend that we were discussing it on chat a lot and
 > all the lights were green so to say and ppl. encouraged me to
 > commit it, so i bypassed the mailing lists yes where i should have
 > queried them.

All which lights were green? You've changed one of the fundamental
user/kernel APIs. Changes like this are supposed to require explicit
approval by core as well as extensive bikeshedding^W design
discussion. There's a reason for that.

Consequently, the changes should be reverted, at least until the
design has been gone through carefully.

While this approach may seem pragmatic for supporting the usermode
kernel, it's far from clear whether it's useful or desirable
functionality in the long term. It's also not clear that it's
functionality we want to provide to application code. It serves no
other real purpose than supporting the usermode kernel. (Handwavy
"security" arguments do not count.)

Furthermore, the interface you've created to this functionality, which
includes several new highly exposed symbols and apparently a reserved
range of bits in the mmap flags, is a major change with long-term
implications. Is this something we want? I doubt it.

Other issues you don't seem to have even thought about include:
   - are your new symbols polluting restricted application namespaces?
   - are you expecting other OSes to pick up this functionality and
     interface?
   - is adding a potentially expensive test on the system call
     critical path really a good idea?

Moreover, if you make the usermode kernel rely on this interface, you
are (for the immediate future at least) restricting the usermode
kernel to running only on NetBSD and only on NetBSD-current. If you're
going to accept this limitation there are a wide range of alternative
approaches, ranging from ptrace extensions to a custom emulation type,
that you could take instead to avoid making changes to core system
interfaces. Have you *really* considered these alternatives?

And finally: do you want it to be impossible for processes running on
the usermode kernel to break out and access the host kernel? That
seems like a good approach but this method doesn't and can't
accomplish that.

-- 
David A. Holland
dholland%netbsd.org@localhost