modular -> monolithic

[Dave Airlie]

On Jan 21, 2008 7:02 AM, Andrew Oakley <andrew at ado.is-a-geek.net> wrote:
> The reason for putting drivers back into the server tree seems to be
> knowing when someone breaks a driver compile.  Surely we can find
> breakages in the tree with a "continuous integration" type system?
>

Actually my primary reason isn't anything like that, I only suggested
it offhand as a solution to that problem..

My issue is that X.org thinks it has a stable mature ABI for drivers,
and this simply isn't true, it actually has had a number of good ABIs
with a number of really bad but solidified over years of hacking
around them ABIs (PCI being one, DRI is fun at times etc.). Now the
devprivates and libpciaccess changes have proven to go forward with
any sense of cleanliness we need to change the API/ABI, doing this is
easier if all the drivers are in the one tree and can be updated at
the one time. (git-grep for example works a lot better). People have
proven they will not no matter what sort of tinderboxing we have build
all the drivers we ship separately. We have had a tinderbox, green for
a day, red for ever...

And as discussed on irc, I don't believe this is the monolith, the
monolith carried all kinds of things an X server shouldn't ship (like
client libraries), yes it is monolithic X server/drivers but calling
something the monolith brings back either 2001 (the movie) flashbacks
or 2001 (XFree86 4.1) flashbacks.

Hmm kbuild for X.org could be fun..

Dave.

> Obviously we couldn't test on all the platforms or configurations, but
> at least we would know what was broken and what worked.
>
> There would also be a question of what to do when the build failed, but
> presumably we would know who was responsible for the commit which broke
> the build.
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>