On Mon, 2003-03-03 at 08:27, Alan Cox wrote: Sven,
Thanks for posting this. I was actually waiting for the fbdev maintainers (Geert and James) to respond first. Seems Geert is receptive to the idea. > On Sun, 2003-03-02 at 21:57, Sven Luther wrote: > > 1. fbdev will be secure. Without access to the MMIO regions, crashing > > the chipset is unlikely or at least difficult. Even malicious blit > > commands (blits to/from system memory) will not work. > > For some cases. The truth is a bit more horrible, and current fbdev has > the same problem here. Any early Athlon, and almost any PII/PIII derived > chip allows the user to bring the box down if they have access to > a mix of cached and uncached RAM. > I do not understand. Do you mean such as writing to framebuffer memory and making it execute? [snip] > > In linux-2.5, fbcon is already separate from fbdev. Perhaps in 2.7, > > fbdev can be further reduced to a minimal core, moving the rest of the > > code to fbaa. Exporting the mmio regions to userland must be > > disallowed. > > I disagree here. There are chips with useful safe mmio areas for many > things. "Exporting mmio regions must be up to the DRM layer" > I was speaking more of fbdev which allows mmapping of the mmio besides graphics memory. DirectFB does its acceleration this way. So, yes, this task can relegated to DRM. > > Any comments? > > Take a look at the SiS DRM. It has the memory manager and fb in one > module but otherwise its not that disimilar to your basic description > Thanks. Tony ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
