<jeffl@melb.arc.cpr.itg.telecom.com.au> writes:
>> If you want a "real console," as you'd defined it, put it in
>> user-land.  period.
>
>If this can be done, fine.

Let me point out that X is a user-land program.  Anything which can be
done by X, could be done by any other user land program.  If the 
features which you seek are sufficiently useful, they can be implemented
in user-land.  I *strongly* advise against kernel bloat.

As I understand it, (and I am not an X hacker) X asks the kernel for
a pointer to the screen and uses that to take over the display, no?

If you find or write code for a super-console which handles the mouse
and draws menu-bars and function buttons, and whatnot, (ick!) then it 
can do likewise.  There is no need for it to live in the kernel.


Here are some reasons for user-space:
1. It is *much* easier to debug code in user-space than in kernel-space.
2. Code in user-space can be installed and removed easily.
3. Compatibility/similarity to other unixen. (this is not so important)
4. The nature of unix processes makes it inherently fault tolerant.

Here are some reasons for kernel-space:
1. The kernel will be bigger and thus consume more memory/disk space!
2. People won't have to use rc files to configure their system when
   they can recompile the kernel instead!
3. ?

(sorry for mild sarcasm)

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