Re: DRM code reorganization

[Ian Romanick]

Jon Smirl wrote:
> > 4) DRM code reorganization. There were several requests to reorganize
> > DRM to more closely follow the Linux kernel guidelines. This
> > reorganization should occur before new features are added.
>
> What should be the model for reorganizing DRM? An obvious change is
> eliminate the naming macros. 
>
> Another is to change to a personality with helper library model like
> fbdev has. All of the common DRM code would go into a library module.
> Each card would then have a small device specific module which depends
> on the library module for common code. 

This would be *very* non-trivial to do.  Doing the DRM like this has 
come up probably a dozen times (or more) over the last 3 years.  The 
problem is that each driver has different needs based on hardware 
functionality.  We've managed to classify these needs into a few groups, 
and drivers can select which functionality they need via a set of 
defines.  These per-driver defines determine what code gets compiled 
into the different routines (as well as which routines even get built).

Trying to make this into a library would just be a mess.  It would 
either break cases where multiple DRMs are built (or loaded) into the 
kernel or result in a *ton* of unused, nearly duplicate routines being 
built into the library.

If this is something that we really want to pursue, someone needs to dig 
in and figure out:

1. How much / which code can be "trivially" shared?
2. How much / which code can be shared with very little work?
3. How much / which code would we rather get a root-canal than try to 
make shared?

The concern has been that, by making a "generic" library layer, we'd 
actually make the DRM more difficult to maintain.  Nobody has really had 
the time to do the research required to either substantiate or refute 
those claims.  Based on the little experience I have in the DRM, I tend 
to believe them.

> 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.  That memory 
manager only exists to support an NV_vertex_array_range-like extension 
that some Tungsten customers needed.  I don't think there would be any 
benefit to making that swappable.

Once the new memory manager is in, 80% (or more) of the code will be in 
user-mode anyway.  The code that will be in the kernel should be generic 
enough to be completely sharable (i.e., in a generic DRM library).

> Are other structure changes needed?
-
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/