Re: DRM code reorganization

[Eric Anholt <eta@lclark.edu>]

On Mon, 2004-08-02 at 11:57, Dave Jones wrote:
> I don't maintain upstream DRM, but I have a fair amount of responsibility
> regarding the Fedora kernel, and I'll state publically that looking at
> bugs in drivers/char/drm is right up there on my list of
> "things I'd rather not do after lunch". Maintainability goes much
> further than 'the guy that wrote the code can grok it'.
> 
> People trying to pick up 3d driver programming on Linux have a huge
> hurdle in their place, as that code resembles *NO OTHER* driver code
> in the tree.

Here, I'd note that I got started in the DRM because I was interested in
3D drivers, but the actual 3D drivers were far bigger hurdles compared
to understanding even some nasty kernel spaghetti.

Of course, this is not to say that we don't have a ton of room for
improvement in the DRM, without even going back to having a generic DRM
library.  One of the things that I think would be nice to see is the
gamma DMA made to be like the rest of the drivers, in which case a lot
of code related to just that driver could be removed.  We could also do
some significant cleanups if we could allow ourselves to remove old
interface mistakes eventually.  This has been made harder than it should
be by the long turnaround times for new monolithic X releases, which is
finally changing now.

>  > >ian: what about splitting the current memory management code into a
>  > >module that can be swapped for your new version?
>  > 
>  > AFAIK, the only drivers that have any sort of in-kernel memory manager 
>  > are the radeon (only used by the R200 driver) and i830.
> 
> ISTR SiS has some memory management code too, though I've not looked
> too closely at that for a long time.

The SiS (and via, which copied it) memory management has way too much
code for what little it has to do.  I've replaced it and made it smaller
in terms of code and binary size, 64-bit clean, and (I think) much more
readable.  I'm going to take a look at committing it once I can drag
myself away from X.Org, at which point someone with via hardware could
do the same for theirs.

-- 
Eric Anholt                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org