On Fri, Mar 19, 2010 at 06:26:03PM +0100, Nicolai Haehnle wrote:
> On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen <l...@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.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
