drm request 3
in [Kernel]
|
Prev: [GIT PULL] SLAB updates for 2.6.34-rc1
Next: [PATCH 1/1] perf: add support for arch-dependent symbolic event names to "perf stat"
From: Linus Torvalds on 4 Mar 2010 13:20 Hmm. What the hell am I supposed to do about (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 (EE) NOUVEAU(0): 879: now? What happened to the whole backwards compatibility thing? I wasn't even warned that this breaks existing user space. That makes it impossible to _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid model, lots of people are just using some random distribution (F12 in my case), and you just broke it. I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs <bskeggs(a)redhat.com> Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com> Signed-off-by: Francisco Jerez <currojerez(a)riseup.net> but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. We can't just go around breaking peoples setups. This driver is, like it or not, used by Fedora-12 (and probably other distros). It may say "staging", but that doesn't change the fact that it's in production use by huge distributions. Flag days aren't acceptable. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jesse Barnes on 4 Mar 2010 13:40 On Thu, 4 Mar 2010 10:36:55 -0800 Jesse Barnes <jbarnes(a)virtuousgeek.org> wrote: > Yes Dave probably should have mentioned it in his pull request, but > that doesn't seem to be a good reason not to pull imo... And now I see Dave did mention this, so what gives. Guidance please. -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matt Turner on 4 Mar 2010 13:40 On Thu, Mar 4, 2010 at 1:18 PM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > but why the hell wasn't I made aware of it before-hand? Quite frankly, I > probably wouldn't have pulled it. From Dave's initial pull request "[git pull] drm merge" from March 1, he does say > *NOTE* in case you missed it: this will *break* your nvidia machine, its purely > intentional. Rawhide should have the libdrm and driver updates necessary. Matt Turner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 4 Mar 2010 13:50 On Thu, 4 Mar 2010, Jesse Barnes wrote: > > Whoa, so breaking ABI in staging drivers isn't ok? Lots of other > staging drivers are shipped by distros with compatible userspaces, but I > thought the whole point of staging was to fix up ABIs before they > became mainstream and had backwards compat guarantees, meaning that > breakage was to be expected? If the staging driver isn't in common use, who cares? But this is a major driver, used by a major subsystem in a major distribution. It's not like Fedora-12 is some odd case. And it's not like nVidia graphics is unusual. Face it, nouveau is "staging" only in name. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jesse Barnes on 4 Mar 2010 14:00
On Thu, 4 Mar 2010 10:51:20 -0800 (PST) Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > > On Thu, 4 Mar 2010, Jesse Barnes wrote: > > > On Thu, 4 Mar 2010 10:36:55 -0800 > > Jesse Barnes <jbarnes(a)virtuousgeek.org> wrote: > > > Yes Dave probably should have mentioned it in his pull request, but > > > that doesn't seem to be a good reason not to pull imo... > > > > And now I see Dave did mention this, so what gives. Guidance please. > > Yeah, it's in the first one. My bad. I didn't notice, because that one got > cancelled for other reasons and never even tested. > > That doesn't change the simple basic issue: how are people with Fedora-12 > going to test any kernel out now? And are there libdrm versions that can > handle _both_ cases, so that people can bisect things? IOW, even if you > have a new libdrm, will it then work with the _old_ kernel too? > > Backwards compatibility is really important. Sure it is. But OTOH this is very clearly a "use at your own risk" driver. Dave and the nouveau guys include the driver in Fedora to get much needed test coverage, and make sure the latest bits in rawhide work together. The "use at your own risk" part is that you get to keep both pieces if you try to mix and match kernels and userspace until the STAGING moniker is removed. If marking the driver as staging doesn't allow them to break ABI when they need to, then it seems like they'll have no choice but to either remove the driver from upstream and only submit it when the ABI is stable, or fork the driver and submit a new one only when the ABI is stable. Neither seem particularly attractive. Of course I'm implicitly trusting their motivation for breaking ABI in this case, but that was very much a part of the merge discussion so shouldn't come as a surprise to anyone. -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |