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: Matthew Garrett on 4 Mar 2010 14:20 On Thu, Mar 04, 2010 at 10:51:20AM -0800, Linus Torvalds wrote: > 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? F-12 continues to ship the -nv driver, which will work fine with any kernel version as long as nouveau is disabled. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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 14:20 On Thu, 4 Mar 2010, Matthew Garrett wrote: > > If you'd made it clear that you wanted the interface to be stable > before it got merged, I suspect that it simply wouldn't have been merged > until the interface was stable. What kind of excuse is that? It's "we did bad things, but if we didn't do those bad things, we'd have done _other_ bad things"? Two wrong choices don't make a right. Nobody has even answered me whether this is _forwards_compatible. It clearly isn't backwards-compatible. IOW, is there _any_ way to move back-and-forth over that commit, even if I can find a new libdrm? IOW, we know we have a problem here. But what's the solution? I know I can revert it (I tried, I'm running that kernel now, nouveau works). That's not a good solution, I know. But can you offer me a _better_ one? One that doesn't involve "upgrade all the way to rawhide, and lose the ability to bisect anything, or run plain 2.6.33". So yes, I'm complaining. But I at least have mentioned one solution. You, in contast, are just making excuses with no solutions. 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: Matthew Garrett on 4 Mar 2010 14:30 On Thu, Mar 04, 2010 at 11:14:11AM -0800, Linus Torvalds wrote: > > > On Thu, 4 Mar 2010, Matthew Garrett wrote: > > > > If you'd made it clear that you wanted the interface to be stable > > before it got merged, I suspect that it simply wouldn't have been merged > > until the interface was stable. > > What kind of excuse is that? It's "we did bad things, but if we didn't do > those bad things, we'd have done _other_ bad things"? > > Two wrong choices don't make a right. > > Nobody has even answered me whether this is _forwards_compatible. It > clearly isn't backwards-compatible. IOW, is there _any_ way to move > back-and-forth over that commit, even if I can find a new libdrm? Judging by http://cgit.freedesktop.org/mesa/drm/commit/?id=b496c63143e9a4ca02011582329bce2df99d9b7c , no. And if you're unhappy with that, don't use the driver. You enabled an option that's *documented* as potentially breaking between kernel releases, having been told that this was likely to happen, and now you're complaining? > IOW, we know we have a problem here. But what's the solution? I know I can > revert it (I tried, I'm running that kernel now, nouveau works). That's > not a good solution, I know. But can you offer me a _better_ one? One that > doesn't involve "upgrade all the way to rawhide, and lose the ability to > bisect anything, or run plain 2.6.33". Running -nv ought to be an option. > So yes, I'm complaining. But I at least have mentioned one solution. You, > in contast, are just making excuses with no solutions. You're asking volunteers who didn't ask for their driver to be merged to perform more work in order to support users they didn't ask for. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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:40 On Thu, 4 Mar 2010 11:08:07 -0800 (PST) Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > The thing is, they clearly didn't even _try_ to make anything compatible. > See how all the ioctl numbers were moved around. > > And if you can't make if backwards compatible, at least you should make it > forwards-compatible. Is it even that? I don't know. I'm kind of afraid it > isn't. The new libdrm required for it certainly hasn't been pushed to > Fedora-12. Will it ever be? And if it is, can you still run an old kernel > on it? Sure, but both kinds of compat come at a cost, a potentially large one in this case, so why take it on before absolutely necessary? I know you can see both sides of this... > And btw, I'd complain about breaking backwards compatibility even if it > wasn't just my own machine. I can pretty much guarantee that I'm not going > to be the only one hitting this issue. Right, but OTOH it's a development driver. If you're running Fedora, things will work as long as you stick to the distro packages. And if you're building your own kernels, you ought to be taking care with staging drivers, right? > So practically speaking: what _do_ you suggest we do about all the > regressions this will cause? Before this thread I thought the policy was "let people muddle through" with staging drivers until their staging status is cleared. If that's not the case, then really what's the point of staging? I'm sure there are other examples of this type of breakage in staging drivers, though admittedly nouveau is probably the biggest in terms of user interest. -- 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: Jeff Garzik on 4 Mar 2010 14:40
On 03/04/2010 02:04 PM, Matthew Garrett wrote: > "Please note that these drivers are under heavy development, may or may > not work, and may contain userspace interfaces that most likely will be > changed in the near future." Shipping it as the default Fedora driver for NVIDIA hardware makes that text largely irrelevant. Jesse said > 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. but when it is the default driver, it is the default _production_ driver for Fedora users, in an official, stable Fedora release. And the alternative? You said > F-12 continues to ship the -nv driver, which will work fine with any > kernel version as long as nouveau is disabled. FAIL. I actually tried that. Have you? Do you think it is remotely easy for a technically component, non-Xorg-hacker type to accomplish? I attempted to use the non-default 'nv' driver just before nouveau was merged into upstream/staging, because I wanted a development kernel that actually worked on my Fedora-based devel boxes. It was a complete exercise in frustration, requiring at least one bugzilla bug report, and ultimately resulted in failure. I gave up and waiting for Linus to merge nouveau, which instantly made my life a lot easier :) Kernel hacking on Fedora, my own dogfood, has become increasingly cumbersome because of all these graphics issues. Sometimes it's just easier to test a modern kernel on an ancient distro, sadly. Jeff -- 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/ |