--- Alan Cox <[EMAIL PROTECTED]> wrote:
> On Iau, 2004-05-13 at 01:58, Jon Smirl wrote:
> > --- Alan Cox <[EMAIL PROTECTED]> wrote:
> > > argument for _good_ console support becomes that after boot you run a
> > > graphical user space console app built with OpenGL, antialiased true
> >
> > When I proposed this a couple of months back both you and Linus called me
> > insane. I need to go find those posts.
>
> At the time you seemed to want to get rid of the actual in kernel
> basic console - that is why.
>
> > There is still a master kernel based console that handles boot, printk, oops
> and
> > kdbg. Each head will use the kernel based console to implement SAK.
> Ctrl-Alt-Del
> > gets you SAK, SysReq get you the kernel console. No logins on the kernel
> console
> > it is write only
>
> No it needs to be read/write. You want it for embedded setups, for
> debugging and for all those inconvenient "rescue the computer"
> situations. (and for kernel debuggers..)
>
I was too strict in saying write only, I listed kdbg as a user and it obviously
needs read/write. Same for a system that needs fsck. If you booted in single
user mode it would probably come up on this console too.
I've reading though the code for some of the other arch's and this is the model
I'm currently thinking about:
1) Boot console. This is implement via BIOS support. It is used to printk a
processor initialization failure or failure to find initramfs. Some embedded
systems might have to build one of these into the kernel but not a normal
desktop machine. This is the kind of console you use to write grub/lilo. It
looks like all non-86, non-Mac archs already have this.
2) System console. An soon as initramfs is up and early user space is active
this console initializes. When it starts, Boot console disappears. This console
is used for: SAK, kdbg, OOPs, printk, single, fsck, etc. The user space code is
used to probe monitor DDC. The kernel driver for this is based on a DRM/fbdev
merge. You can use SysReq to hotkey to this console at any time. This console is
implemented in the kernel.
3) User console. A normal login gets one of these. It will probably be generated
by a user space app implement on OpenGL with fancy fonts, unicode, etc. The user
is assigned ownership of their video device which allows direct rendering.
Multiple copies of this app can be running, each providing an independent user
console on each video device. Kernel VT and terminal emulation support is pushed
into this user space app.
When User console is up it is using the full OpenGL driver. xserver would use
the same OpenGL driver. The User console app and xserver could even be the same
program. If User console/xserver dies, you can always user SAK to relaunch if it
doesn't happen automatically.
=====
Jon Smirl
[EMAIL PROTECTED]
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
