I'm really tired right now (three hours of sleep), so I know this will
be a fun message.

Basically, I agree with the content of everything Chris has said.
Anything not having to do with process control and communication or
hardware interfacing should not be in the kernel.  This means us.

Virtual terminals have been in the kernel for quite some time.  They
probably should not have been in there, but the code took a few hours
to write on a Saturday morning (kudos to Lawrence), and we didn't feel
the need to review code that worked nearly perfectly and took almost no
pain to put in.  So they stayed; it was not necessary to argue about them
because there was no practical reason to remove them.

The new kernel DESKTOP code is much bigger.  A large chunk of it is
there as support for multiple ADB subsystems (per machine class) and
devices, but a lot of it is needless scrolling code, multiple screen
support, and so on.  That code should be removed and placed in a
user-level program.  The kernel should have a basic single terminal
console emulator with only keyboard support.  (I also argue for VT102
support; there are times that I'll want to run VI while in single user
mode, but that's debatable.)  Certainly this approach would be
philosophically much cleaner, not to mention the significant gains in
reliability and compile cycle speed.

Still, the console code works, and most of the panicking bugs have
already been fixed.  It's made my development much faster and I find
it extremely convenient.  Although that's not a good excuse to keep it,
there are a lot of other things I could do now besides extracting that
code from the kernel.  Some that come to mind are IIsi support,
interrupt- driven SCSI, and color support for X-windows.

(By the way, X11R6 runs *very* well.)

Of course, to be fully pure about kernel design, I expect some other
items should be removed from the kernel, like SL/IP, NFS, the Berkeley
Packet Filters, and anything which doesn't handle essential machine
control.

My stance is this: we *should* spend time removing the code that is
already in the kernel and provide a much cleaner setup, but I have a
lot of other stuff I'd like to do before code freeze THIS THURSDAY.
Lawrence has volunteered to user-ize the code himself, although I'm
sure the MacBSD community would much more enjoy other fruits of his
labors.  If I have the inclination, I will help him.  Virtual consoles,
pointer cut and paste, scrolling, and multi-screen support will all
probably eventually end up as a user level program.

Finally, I would like to express my anger at Chris, who apparently
feels the need to gratuitously insult both the BSD user community and
its developers.  In an environment where we should all be helpful to and
tolerant of each other, I continuously feel that my contributions to
the NetBSD project are not welcome and I have to struggle, sometimes,
to justify huddling under NetBSD's wing when we get pecked at so
often.  I am not surprised that many other developers feel so alienated
by the NetBSD core members' behavior that they have taken their own
efforts elsewhere!

That said, I will continue to accept constructive criticism and add my
part to MacBSD, and hope that it continues to be as rewarding to myself
and the community as it has been in the past.

		-Brad
-- 
 '1' means a BLACK pixel, '1' means button UP, what will Apple think of next?
Brad Grantham, grantham@netcom.com >+------+< Happily slaved to NetBSD/Mac68k!
	I thought I would have to go without dinner tonight until I
       remembered the container of chocolate frosting in the fridge!

------------------------------------------------------------------------------