Re: Resource management.

[Jon Smirl <jonsmirl@gmail.com>]

On Mon, 21 Feb 2005 23:25:15 +0000 (GMT), James Simmons
<jsimmons@www.infradead.org> wrote:
>         So we don't end up with a struct fb_info constantly growing with struct
> fb_pixmaps. At present we have pixmap and sprite in struct fb_info. In the
> future we will have more. I need to create a pixmap for the framebuffer
> itself. This way we can have hooks for inbuf and outbuf to deal with
> issues of devices that have hardware restriction when writing to the
> framebuffer. The classic example is the Epson135X chipsets. You can only
> write/read 16 bits at a time with the framebuffer. Also in the future I
> plan to add DMA support. One approach to this is pci_pools. This would
> require multiple fb_pixmaps. One for each area for DMA you request. Of
> course we could have a static array of struct fb_pixmaps but there is no
> guarantee that the orders will be the same for each driver.
> 
> Do you see any other solution to this then?

You could build this inside of the DRM framework which already
supports DMA and memory management. DRM doesn't really know anything
about 3D, it just knows how to send commands to the graphics hardware.
It's the mesa layer in user space that knows about 3D.

There is a lot of code inside DRM to stop a DRM user from using the
DMA hardware to play with kernel memory and gain root priv. fbdev will
need the same protection if it starts using DMA.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click