[Mesa3d-dev] DRI SDK and modularized drivers.

[Nicolai Haehnle]

On Mon, Mar 22, 2010 at 2:24 AM, Luc Verhaegen <libv at skynet.be> wrote:
>> 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?

Why not?

Mind you, I'm not advocating for any change at all, but as long as you
feel the need to move stuff around, why not try finding a goal that
people actually find useful? Of course, my suggestion is probably
crap, too.


[snip]
> 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.

Nobody has ever had to feel the pain of a separation between Mesa core
and drivers. And since a git log I've just done tells me that you have
committed only twice to the Mesa repository within the last year or
so, maybe you should listen to the opinion of people who *have* been
active in the Mesa tree when it comes to that subject, and are working
on drivers that are probably significantly more involved than whatever
Unichrome does.


>> 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.

And that has worked so well in the past.

cu,
Nicolai