stripping off "xf86-*-" from drivers

[Luc Verhaegen]

On Sun, Jan 20, 2008 at 02:26:21AM -0800, David Miller wrote:
> From: Alan Coopersmith <Alan.Coopersmith at Sun.COM>
> Date: Sat, 19 Jan 2008 22:52:19 -0800
> 
> > Dave Airlie wrote:
> > > Granted I'd be happy to move all the open source drivers back into the
> > > server build and get rid of whole idea of a stable ABI between
> > > releases...
> > 
> > But then you'ld have to get all the driver maintainers to meet the
> > release cycles of the X server, instead of letting Intel release
> > quarterly, while ATI does developer snapshots for a year between
> > stable releases.
> 
> Even so, I really like Dave's idea.

Why? Why can anyone agree with "Let's go monolithic again so that i 
still do not have to bother in any way about being slightly backwards 
compatible".
 
> It's just a mess currently.  Look at the Xserver SELINUX changes from
> the other week.  The GC private et al. bits broke several drivers
> including those I care about (mainly sparc ones).
> 
> The input driver breakage that was measured in years would never have
> happened if all the drivers were in the tree and typing "make" would
> show everything that breaks from an API change.

libpciaccess.

I don't think there has been anything worse than this.

> There is nothing that keeps drivers building when people make X server
> API changes, nothing.
> 
> So what happens?  Shit breaks all the time, there are countless
> examples and it nearly happens on a weekly basis if not more often.
> 
> It's a huge quality control issue.
> 
> It would be one thing if people were diligent and validated the
> build of all the drivers, but people who have write access to
> the X server and driver sources have demonstrated over and over
> that they absolutely lack this level of care.

This is one part of the solution. Tinderbox should be revived, and those 
who commit stuff to master or a release branch need to get blamed for 
any build breakage. This will solve a lot of the issues already. A lot, 
but not all.
 
> This did not happen on this level beforehand.

Because this is not the shared mindset.

> Want to know what the biggest joke is?  Those build directions
> published on the web and the build.sh script in the tree.  You
> know why?  Because the tree is never in a state where everything
> actually builds!

Right. This is the real problem. People are only developing for the tip 
of everything else, instead of trying to be slightly backwards 
compatible, where possible. Where this is not possible, a choice needs 
to be made, either do not compile the new features that have a new 
dependency, or to stop building against this.

But in any case, it pays to have a window of compatibility. This way 
slightly older servers can benefit from the hardware support new drivers 
offer. Or this way the server can still build even though the system 
doesn't have some unreleased version of some library yet.

Once you accept such a window of compatibility and start working towards 
it, and change your mindset, you usually see how easy it is to keep 
things compatible.

Twini knew this for his sis driver, which, at the time, was buildtime 
compatible all the way to xfree86 4.2.0. My unichrome code did so up to 
4.3.0 (debian sarge). And now radeonhd goes back to X.org 6.9, and if we 
adjust a buildflag, earlier too. With only a minimal amount of work.

For drivers, 6.9 is not too insane either, it is actually still being 
shipped and its use is still widespread. Giving it newer hardware 
support, even with reduced functionality, is a must. And even with the 
reduced functionality, it always beats running vesa.

Luc Verhaegen.
SUSE/Novell X Driver Developer.