Hi, On 17 September 2011 12:04, Matthieu Herrb <matthieu.he...@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 _______________________________________________ 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