Re: [Linux-fbdev-devel] Resource management.

From: James Simmons
Date: Mon Feb 21 2005 - 22:55:29 EST



> > 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.

I have CC the dri list to discuss the issues. I have looked at the DRI
code. I know merging dri and fbdev infrastructres has been discussed
before. There are a few issues that have always prevented this. Now
I'm going to go over the issues.

1. Lots of work that would take lots of time. To my knowledge all fbdev
developers work in there spare free time. No one does this for a
living.

2. Sharing of headers. The dri headers are isolated in the drm directory.
I totally understand why :-) It makes merging easier for them. The
disadvantage is no one in the fbdev can use them easily :-(

3. DRM has way to much functionality for most embedded devices. I have
talked to embedded guys before and they want a simple api to work with.
By default DRM builds in everything. A simple api mean alot to those
guys. Plus the extra built in code bloat takes up to much space which
is precious on embedded devices. If a devices doesn't support dma then
the dma code doesn't need to be built in.

4. Which comes to the next point. The code is not modular enough. Take
drm_bufs.c. Everything is a ioctl function. This has a few disadvantages.
One is the fbdev layer couldn't just link into it so fbcon could use
it. The second is it's not easy to take advantage of things like sysfs.
If you could untangle the code somewhat it would make life so much
easier. That would include making life easier for OS ports.

5. The license issue. The DRI code is GPL and additional rights. What is that?

For the fbdev layer we would need a layer on top of the drm data
structures because we need to know things in the kernel to draw images
for font characters i.e how much byte padding is need for images.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/