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

Actually, there are _good_ reasons to keep virtual consoles in
the kernel, and i've detailed them to you and Lawrence in private mail.

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

Ahh, well, in that case you'd also remove the file systems, because
they have nothing to do with machine control!  And don't forget the
networking code; it, too, has nothing to do with machine control.

The point is, assuming a BSD-style kernel, there are some things which
can be implemented _only_ in kernel-mode code.  Those include things
like NFS, SLIP, the rest of the file systems, the networking code,
and BPF.  Then there are other things, which can, and should be
implemented in user-land code, such as a console "thang", should
not even be _thought_ about in the same context as kernel-mode
code.


the following _doesn't_ particularly belong in a public message,
but it really has to be, because there are some things that need to be
set straight.

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

Actually, i find that entire paragraph rather amusing.  For the
record, the rest of the people working on NetBSD ports typically
communicate with members of 'core' every few days or so.  In general,
'core' hears from the various people working on the macintosh port
once in a blue moon.  In other words, if you'd like to communicate
with the people in 'core', TRY IT, DAMNIT; you can't say that
we 'alienated you' from the start, because the people working
on the mac port have _never_ talked to us significantly more
frequently than that.

As i said to you in private mail an hour ago, if you had told us what
you were up to, and what was being planned for your console driver,
we would have had a _hell_ of a long time to convince you that it was
a very bad idea to do that way, etc., and we would have been a hell of
a lot more patient with explaining to you why.

But when you say, "this is the way the console driver is being done,"
when "that way" is quite antithetical to the way UN*X-like kernels
"should be" designed, and when that design was done without
consultation of *anyone* else, then you cannot expect me, as one of the
people who has to try to maintain overall code quality in NetBSD,
to sit by quietly.  (Note that asterisks around anyone; that means
the people in NetBSD's core group, and probably most of the people
in the Mac porting group -- I doubt Allen, who was reasonably vocal in
this public forum, would have been quiet if he'd heard the idea
in private previously!)


I've offered apologies to anyone who i thought might deserve them
(i.e. Jeff L. and Lawrence).  However, the fact that i (quite
rightly!) feel strongly about some matters does _NOT_ absolve *you* of
your obligation as a memeber of the _team_ of people working on NetBSD
to communicate with the other members of that team, and it's _that_
lack of communication that caused most of this problem to begin with.


Also, about your statements about: "well, there are better things that
we could be doing in the next N days than ripping out console code."
I'm not sure that i buy that.  When you do a release, you want it to
be as representative of your works as you think you can make it.  One
of the things that that should mean, since you're writing a UN*X-like
system, is that it's well designed.  So yes, if i were you, i _would_
rip out the desktop thang from the console code before the release!



chris

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