Xserver driver merging pros & cons

[Luc Verhaegen]

I just rejoined the land of the living after returning from Chicago 
just yesterday, hence the lack of response earlier.

On Thu, Sep 15, 2011 at 10:45:17AM -0500, Jesse Barnes wrote:
> At XDC this week we discussed merging drivers back into the server
> tree.  One thing I found frustrating about the discussion was that we
> didn't have a whiteboard nor a list of the pros & cons of such a
> change.  So I'd like to capture that here (from memory) to let us
> continue the discussion about whether it's worth it or not.
> 
> Luc, I think you're the most vocal opponent of this move, so I've cc'd
> you so you can enumerate any issues I've forgotten.
> 
> Anyway, as I recall, the issues are as follows:
> 
> Pros:
>   1) easier to propagate API changes across drivers (just like Linux)
>      1a) thus easier to change ABI

This seems like something tinderbox should be catching. And the overhead 
of adjusting multiple drivers is mostly just a git checkout, and 
separate git send-email more. Not enough to warrant a change, let alone 
to cancel out the disadvantages.

>   2) developers focused on driver development now have more incentive
>      to make sure the server works well so regular releases can still
>      happen (i.e. more people working on blockers whether driver or not
>      as releases approach)

Hrm. Again, tinderbox, and besides that, a general issue of maintenance.
You are still putting the burden of updating the drivers to suit 
infrastructure at the driver developers, and not at the people who alter 
infrastructure.

If you had promised that this move would finally no longer give people 
an excuse not to:
a) come up with solutions which best suit all drivers
b) update all drivers, or at least be part of the process of updating 
all the drivers, to match the changes in infrastructure
c) thoroughly build test everything. 
Then you would have some sort of a point here.

But honestly, i cannot see why none of the above can be promised in the 
current constellation.

>   3) allows removal of driver compat code for various server versions
>      3a) thus removes combinations of driver+server that developers
>          have to support & test

Err. Today it is already up to the driver developers to decide which 
backwards compatibility code to keep for which amount of time. Moving 
drivers in tree does not need to translate in this changing.

In fact, Keithp was loudly proclaiming that the intel driver will keep 
compat code. How long this claim will be upheld, and what time/releases 
window this will end up being, remains to be seen.

>   4) increased test coverage for the server as users wanting current
>      driver code will be building new servers too

Killed by Con 2. And... Most of the issues are driver side, you'd rather 
give people the ability to update their drivers than to have them update 
their Xserver. That makes for a much improved user experience and thus 
increased X/linux/whatever acceptance.

> Cons:
>   1) more work for distros to backport just driver changes to old
>      servers (especially if people follow through on (3) above)
>      1a) if backporting is harder, new hardware support will be more
>          difficult to land in "enterprise" level distros

The enterprise distributors are the ones who supposedly get paid to 
maintain such things. Distributions like debian stable are the ones 
being hurt the most.

All of this is basically a mindset problem.

If changes to drivers were done with more compatibility in mind (ie, 
build time compatibility by disabling newer features when building 
against older infrastructure), then everybody wins. Drivers will become 
better structured because of it, users will more easily be able to pull 
in newer/older drivers and compare the different versions, and 
enterprise vendors should have an easier time keeping basic driver 
functionality on new hardware, beyond the debian stable time limit, 
releasing some resources to improve said infrastructure and drivers.

Infrastructure developers are often also driver developers who need new
features for their hardware. They are best suited to know what needs 
doing. Bystanders often have a much much harder time making the same 
changes. If infrastructure changes are done in the cleanest way possible 
(read, structuring things so that there is no needless fallout and so 
that the changes are transparent and easily enabled/disabled at build 
time), then we are at our most efficient.

If things get badly thought out, and then just get thrown over the 
hedge, then we end up just shooting ourselves in the feet. The way in 
which EXA and libpciaccess/RAC removal were done are great examples 
here. Twini was the first to try EXA on real hardware, at least in a real 
driver (SiS). Libpciaccess/RAC would look quite different, and porting 
drivers would've been a lot easier, if they had been developed with a 
different mindset.

>   2) harder for users to just upgrade drivers independently, now
>      they'll have to build the whole server
>      2a) thus less testing of current driver code from technical users

This is the real world beater. We need more people testing more driver 
code. Infrastructure code is way less prone for failure.

But again, this is a mindset thing. There seems to be no drive to 
change this mindset, just a drive to copy the kernel's working mode 
(which imho, does not work for graphics drivers, which are as complex as 
the hardware they support, with up to 7 or 8 parts spread all over the 
system).

Luc Verhaegen.