--- Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Mon, 9 Feb 2004, Jon Smirl wrote: > > > > There are lots of solutions to this: > > 1) queue the printk's > > 2) add an in-kernel path for write to console that cooperates with the > normal > > user space one > > 3) if you know you are going to be debugging code like this, use an > alternative > > solution like the serial port or a second video card running framebuffer.,
I guess the long response means your in favor of option #2. It should be simple enough to add a 'blue screen of death' to Linux under the proposed model. oops could just call a special DRM entry point. It would leave the monitor in whatever mode it was in, erase the screen, and print the oops. We would just need need to build a minimal bitmap font into DRM so that it is always available. This would work because the proposed DRM driver always knows the current screen mode and where the active video buffer is. You can't implement this right now because everyone is programming the video hardware directly and who knows what state it is in. Assuming we can address the issues with printk and oops, what is your general opinion of a user space console replacing TTY/VC? I thought it would be neat to put five PCI video cards into my machine with five keyboards and use them all at once. ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
