Xserver driver merging pros & cons
matthieu.herrb at laas.fr
Sat Sep 17 04:04:13 PDT 2011
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:
> 1) easier to propagate API changes across drivers (just like Linux)
> 1a) thus easier to change ABI
> 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)
> 3) allows removal of driver compat code for various server versions
> 3a) thus removes combinations of driver+server that developers
> have to support & test
> 4) increased test coverage for the server as users wanting current
> driver code will be building new servers too
> 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
> 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
and as other said it already I think,
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.
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.
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 ).
More information about the xorg-devel