[Mesa3d-dev] DRI SDK and modularized drivers.

[Luc Verhaegen]

On Fri, Mar 19, 2010 at 06:26:03PM +0100, Nicolai Haehnle wrote:
> On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen <libv at skynet.be> wrote:
> > So, identify the volatile interfaces, and the more stable interfaces,
> > and then isolate the volatile ones, and then you come to only one
> > conclusion.
> 
> Except that the Mesa core <-> classic driver interface also wants to
> change from time to time in non-trivial ways, and trying to force a
> separation there on people who don't want an additional set of
> compatibility issues to deal with is not exactly a friendly move.

You have to see this in the global picture. Sure, now it adds one 
additional set of compatibility issues, but it allows for the removal 
or reduction of most of the compatibility issues we are actually hit by 
today; namely, those between the different driver specific bits.

Those driver specific bits are, by their very nature, a lot more 
volatile.

None of this work will stop interface changes, that's the last thing i 
or anyone else wants.

It will however incur a tiny bit more overhead when making interface 
changes between drivers stacks and the outside. But that in itself is 
already outdone by the ease of making driver stack internal changes 
(where more of the pain exists now).

The other advantages are all net gains.

> It may seem e.g. like the DRM interface is the worst because of rather
> large threads caused by certain kernel developer's problems, but that
> doesn't mean problems wouldn't be created by splitting other areas.

Check the timestamps on my unichrome code: most of that work was done in 
november. And it's based on ideas that have been brewing since when i 
still was at suse (as suse, a company trying to sell service around the 
linux desktop, suffers from the current layout).

So it had nothing to do with the nouveau spat at lkml recently. This 
little shouting match is just another symptom that shows that something 
is wrong with the current setup.

> In
> particular, the Mesa core <-> classic driver split only makes sense if
> there are enough people who are actually working on those drivers who
> would support the split. Otherwise, this is bound to lead straight
> into hell.
>
> In a way, the kernel people got it right: put all the drivers in one
> repository, and make building the whole package and having parallel

"put all the drivers in one repository"?

So, all of:
	* drm
	* firmware
	* libdrm
	* xorg
	* mesa/dri
	* mesa/gallium
	* libxvmc
	* libvdpau
	(add more here)
of the same driver stack, in one repository?

> installations trivial. The (only?) issues with that in X.org are that:
> 1) there is a cultural aversion due to the bad experience with the
> horrible pre-modularization setup, and

There was an SDK there, i never used it directly, i built my driver 
against the tree (which was easy too). But I became a _really_ happy 
camper when everyone shipped the xorg sdk per default, heck, i even have 
a full debian build system in unichrome, simply because the sdk allows 
for that.

Now, about building the whole package... This is called a tinderbox, 
this is a part that's easily automated.

The real question is: where is the most pain, and how can we reduce it.
And the most pain is between the driver specific parts.

> 2) it wouldn't actually solve the DRM problems, because we want to
> have the DRM in our codebase, and the kernel people want to have it in
> theirs.

The kernel people can have theirs. What stops anyone from getting the 
drm code of a released driver stack into the next kernel version?

But when anyone decides they need a new driver stack which requires a 
new drm module, it should be easy to replace the stock kernel module.

Luc Verhaegen.