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. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel