Xserver driver merging pros & cons
Luc Verhaegen
libv at skynet.be
Mon Sep 19 08:05:37 PDT 2011
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.
More information about the xorg-devel
mailing list