Xserver driver merging pros & cons

[Daniel Stone]

Hi,

On 17 September 2011 12:04, Matthieu Herrb <matthieu.herrb at laas.fr> wrote:
> On Thu, Sep 15, 2011 at 10:45:17AM -0500, Jesse Barnes wrote:
>> Cons:
>>  [...]
>
>   3) makes it harder to maintain out of tree drivers, since API
>      breaks are not going to be documented anymore.
>      If old pre-kms code start to be removed, the people still
>      depending on them will need a forked X xserver, which is not a
>      good idea at all.

That's not actually true per se.  I don't think anyone has proposed
doing this at all, and as someone who more or less thinks this is a
reasonable idea, I'd be pretty upset if people stopped documenting API
breaks.

Right now, we bump the ABI field in the loader as soon as the first
ABI break of a development series is made for that particular
subsystem, and then keep the ABI static from the first release
candidate of a new major release, right the way through the stable
series.  So yes, it does happen right now, today, that people break
ABI in a development series without bumping the ABI revision.  This is
the reason why the Ubuntu xorg-edgers PPA (an archive providing the
latest X environment) strictly bundles the server and drivers
together.  I haven't really seen anyone complain about this, given
that the ABI is strictly maintained as soon as we hit RC1.

As for the forked server bit, surely this would be relatively easy to
maintain: it'd be easily scriptable to maintain a hybrid tree with the
latest X server and an old driver release.  Of course, you'd need to
be dealing with the ABI breaks yourself and testing it yourself since
no-one would be testing very old driver code with very new servers,
but again, this is exactly the same as today.

The only change people have proposed is pulling the major drivers into
the server tree, so when people do break API/ABI (again, this happens
today), it's much easier to do because somewhere around 99% of X users
will already be covered by what's in-tree.  The other out-of-tree
drivers will get updated when someone notices and updates them,
probably without testing as people don't tend to have hardware like
that lying around (for example, I asserted at XDC that no-one could
say with confidence that the neomagic driver works post-pciaccess and
no-one disagreed; it may work, but that the developer base doesn't
know at all tells you a lot).  Again, this is exactly what happens
today.

> While I've traditionnaly not been opposed to a merge of the drivers
> back to the xserver (since I was originally opposed to the excess of
> modularization), it would be bad if this also made live much harder
> for people trying to support legacy hardware.
>
> So if the drivers are merged back, it's really important to keep the
> notion of driver ABI and bump it when incompatible changes are done.
> External driver can then choose to support several or just one version
> of the ABI, but at least they have a mechanism to identify
> incompatible changes and react on them.

I agree completely, and will argue very very strongly against any
proposal that doesn't maintain this.

> And for the record, I'm still totally opposed to a change of
> license, so, yes the above also applies to GPL licensed
> modules, which need to be kept external (unless their contributors
> want to change their license ).

This is definitely a separate discussion; let's not conflate the two.

Cheers,
Daniel