I've been getting a lot of mail about this both on and off list. First off, very little code has been written, this is just a design concept.
One thing is clear there are two consoles involved. One is the system console that receives printk's, the second is your garden variety command line terminal session. I'd like to explore pushing this second type into user space. One advantage to doing that would be the ability use 3-4 PCI graphics cards to set up a multiuser system. You could even have separate command line sessions on each display head. Implementing a system for displaying printk's to the screen has to cope with another type of problem caused by a xserver that is hardware compositing the entire screen on every vertical retrace. Without coordination anything you write to screen will be gone 1/60th of second later. Full screen games have the same problem. The bigger goal here is that I'm exploring a system that would shut down all direct user space access to the graphics hardware. The graphics hardware would be protected by a single device driver and a user space library is used for accessing it. This type of design accomodates graphics hardware where the VRAM is not visible to the bus. SGI machines already have this and there may be more chips like this in the future. It also stops the free for all where every app is programming the graphics hardware from user space. I've had several discussion now about how to handle printk's in an environment like this. The best one so far is for the graphics driver to hold a log of the printk's it has received. When a new one is received the driver suspends whoever is writing to screen, possibly by letting them continure to write to the back buffer and stopping screen swaps. It then formats the front buffer and paints in it's log of printk's. Note that the front buffer will already be set up for display in the current mode. Formatting and painting is something that can be done at interrupt time. The system would then stay in this state, updating for more printk's, until some kind of input was received (sysreq?). The printk's would also be sent off to some normal command line console where you could look at them and run programs if the system remains stable. One hole in this is what happens if a printk occurs in the middle of a mode switch? or if the display is in a suspended state? This will require some research. Getting the display out of suspend may not be achievable at interrupt time. These aren't new holes, they're there right now for the current console. The above scheme does provide the new feature of making the printks appear while xserver or a game is running. ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel