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: Daniel Stone on 5 Mar 2010 11:10 On Fri, Mar 05, 2010 at 07:48:35AM -0800, David Miller wrote: > From: Daniel Stone <daniel(a)fooishbar.org> > > On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: > >> In fact, I argue that the moment nouveau went into Fedora and > >> was turned on by default, the interfaces needed to be frozen. > > > > That's a matter for the Fedora kernel team; for better or worse, they > > made the choices they did, which included going through all the relevant > > pain to support this. They didn't consider it suitable for upstream > > because they didn't think everyone else should be forced to endure that > > pain. > > By not merging it upstream the pain is larger not smaller. > > It's enabled by default, so you therefore can't test upstream kernels > by default. 'That's a matter for the Fedora kernel team'. > And as I showed already, even if you jump through the hoops to make it > work (building noveau from out of tree in the upstream kernel) you'll > end up getting screwed when the API changes anyways. So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for Xlib. > Using VESA or whatever else you've suggested is just not a reasonable > alternative. > > You can't unleash something like this on a userbase of this magnitude > and then throw your hands up in the air and say "I'm not willing to > support this in a reasonable way." > > We're better than that. Your opinion on what constitutes reasonable support is not universal, absolute truth.
From: David Miller on 5 Mar 2010 11:10 From: Daniel Stone <daniel(a)fooishbar.org> Date: Fri, 5 Mar 2010 18:04:34 +0200 > So you're saying that there's no way to develop any reasonable body of > code for the Linux kernel without committing to keeping your ABI > absolutely rock-solid stable for eternity, no exceptions, ever? Cool, > that worked really well for Xlib. read() still works the same way it did 30 years ago last time I checked. -- 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 5 Mar 2010 11:20 On Fri, 5 Mar 2010, Alan Cox wrote: > > You can't unleash something like this on a userbase of this magnitude > > and then throw your hands up in the air and say "I'm not willing to > > support this in a reasonable way." > > Not to belabour the obvious - they didn't. Linus ordered them to merge it. Alan, you're ignoring reality. This problem existed *before* nouveau was merged. In fact, it was *worse* back then. How hard is that to understand? And yes, I do actually know. Because I used nouveau for a year before it was merged. You had to use a different version of drm too, so you couldn't even just compile the nouveau tree and install just the nouveau driver (and keep the other drivers from the main tree). So the watershed moment was _never_ the "Linus merged it". The watershed moment was always "Fedora started shipping it". That's when the problems with a standard upstream kernel started. Why is that so hard for people to understand? 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: Alan Cox on 5 Mar 2010 11:20 On Fri, 5 Mar 2010 16:56:10 +0100 Luca Barbieri <luca.barbieri(a)gmail.com> wrote: > It seems to me that Linus' technical argument is indeed being mostly ignored. > > While breaking the ABI is unfortunate, the real problem that Linus > complained about is that you can't install several userspace versions > side-by-side. I think you need to be clearer about that. Your distribution packaging may not support that out of the box. There are a variety of ways to do almsot all of this including having entire parallel X installs for development work. All the X builds are modular, all the modular builds support --prefix= with their autogen script. ld.so supports LD_LIBRARY_PATH and the shells support PATH variables. You can replace all or almost any part of X quite easily. There is also a mechanism for versioning within DRM for a lot of stuff, and drivers use flags to make it work nicely except for devel code (which is what Nouveau is) The fundamental problem you can't solve by versioning though is the exact one here. A new kernel that requires version X of a driver won't help if the newest version you have is X - 1. Yeah perhaps Fedora should have pushed an update that was smart enough to handle the Nouveau old/new ABI before the patch went upstream. Hindsight is an exact science. Alan -- 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: Adam Jackson on 5 Mar 2010 11:20
On Thu, 2010-03-04 at 15:03 -0800, Linus Torvalds wrote: > On Thu, 4 Mar 2010, Adam Jackson wrote: > > On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: > > > Two wrong choices don't make a right. > > > > So unmerge it. > > That's what I told people I can do (I'd just revert that commit). Read it more strongly: drop nouveau from your tree entirely. Don't give me any "not a solution" nonsense about that. The problem is entirely that your expectations for interface stability [1] in your tree do not match nouveau's development model and will not for the forseeable future. Yes, they should htfu and version interfaces like real men. But they're not going to, so either enforce your rule or don't. [1] - apparently ignorable when it's inconvenient, but let's not turn this into a sysfs argument. - ajax |