stripping off "xf86-*-" from drivers

[Bernardo Innocenti]

Luc Verhaegen wrote:

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

Because less backwards compatibility constraints result
in more useful development.

It may seem counter-intuitive, but Linux breaks its ABI as
many times as the developers see fit, and *therefore* it
comes with the largest driver base of any existing OS.


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

Putting blame on Ian Romanic for breaking legacy drivers
such as sunleo and chips is, to say the least, unfair.

If you cared about one of the broken drivers for any reason,
you should have posted patches like David Miller did.
Preferably around the same time the pci rework was being
done, working in a branch.

If we agree that cleanups/refactorings such as the
pci-rework one are generally useful, then we shouldn't
discourage whoever volunteers to do them by putting
excessively strict conditions on them.

As my boss often says, "perfect is the enemy of good".


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

I agree with the first part of your proposal: a regression
testsuite, along with a functional tinderbox, is an invaluable
tool to monitor regressions and track them to individual
patches.

I strongly disagree on the notion that we should blame
hard-working people whenever they cause intentional or
unintentional breakage: some amount of care is certainly
required, and a good review process would gratly help...
*BUT* those negative feedback practices are known to engulf
development by putting more blame exactly on those who would
otherwise become the most active and bold contributors.

Many years ago, I've been working in a popular OS project
with this same total-stability attitude.  It has now been
surpassed in popularity and almost killed off by the maybe
imperfect, but very dynamic Linux.

Excessive stability is death :-)


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

I find Xorg *extremely* backwards compatible compared
to anything else I've ever seen.

We only drop features years after they've been deprecated even
if there's no known code out there using it.  The wire protocol
has remained compatible for over 20 years.  We still support
pre-xkb keyboards just for the sake of some obscure UNIX vendoer
which has not even bothered to update their keyboard driver in
10 years.  We have had *working* drivers for some ISA chipsets
until recently.  We're still considering pre-C99 compilers and
even leave the #ifdefs for the Cray around!

Is this amount of backwards compatibility insufficient?


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

Granted... maybe the pci rework could have used a few
wrappers in the server.  I don't know if it was technically
practical, but I guess Ian would have considered it.


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

Whoever is running a museum is free to backport drivers to
xfree86 4.2 and even make them work on the Cray.  These things
are nice to have and welcome in the tree, but not as a drag
for people working on new features for the remaining 99.9%
of the user base.


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

A must for whom?  If there were crazy people who try to plug a
brand new video card in a computer with an OS from 2005
and expect it to magically work, it is their problem, not ours.

Ironically, they could easily upgrade the monolithic Linux
kernel to support any other piece of hardware.  But for a
graphics card, somehow they need to update just the driver
without touching the X server.  Wouldn't it be easier for
both the users and the developers if they could just update
the whole thing?

The X wire protocol is already a natural barrier where backwards
compatibility can be indefinitely maintained with a small cost.
Very similar to the kernel syscall interface.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/