[Mesa3d-dev] DRI SDK and modularized drivers.

[Luc Verhaegen]

On Fri, Mar 19, 2010 at 12:44:39PM -0500, Bridgman, John wrote:
> Pulling drm back out of the kernel tree seems like a hard sell, but the ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for grouping. 
> 
> I guess the core question is whether we expect the X-to-ddx and mesa-to-hw-driver interfaces to be more or less volatile than the ddx-to-libdrm and mesa-hw-driver-to-libdrm interfaces over the next couple of years. 
> 
> On the core-to-driver interface side we have the Gallium3D and GL 3/4 work, and on the libdrm interface side we have ongoing improvements in memory management and command submission. Tough call.
> 
> I guess another option would be a "pseudo-modular" approach where the code stays in the current trees but we adopt versioning and build/test procedures which treat ddx/mesahw/libdrm as a single code base even if the code is still living in multiple projects. That might be an easy first step, but repartitioning the code does seem like a better long-term approach.
> 
> If the drm code were omitted from the proposal and we focused only on ddx/libdrm/mesahw would that help ?

Well, to continue down the same path: It doesn't really matter how 
driver developers want to scatter their own different driver bits around 
today. It should be up to them.

It shouldn't matter, but sadly it does (as you're forced to have them 
into the main trees).

If those developers are free to choose how they want to handle this, 
then it will quickly become clear for some what the best mode of working 
for them really is, as opposed to being forced to work one way.

Then there will be pressure from users, hw and distro vendors, who 
might like one or another way of working better. And i guess that this 
is what those reasoning against this are mostly afraid of. Ideas like 
this can no longer be swept under the carpet with "impossible".

Luc Verhaegen.