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 5 Mar 2010 10:20 On Fri, 5 Mar 2010, "C. Bergstr�m" wrote: > > staging != stable This really is being repeated, over and over. But it's irrelevant. It's irrelevant because it's just a bad _excuse_. That driver is used in production environments. That's _reality_. The whole "staging" thing is nothing more than a meaningless word. And no, "staging" wasn't why it was merged. The reason it was merged was that very same "reality". So every time somebody mentions staging as an argument, he's missing the whole effing point. It also misses the point that the issues I've tried to bring up (bisection, testability) are real _technical_ arguments. Again, waving that "staging" flag is just stupid. It has nothing to do with the technical arguments, or with the reality of the situation. In other words, it's not just an excuse, it's a _meaningless_ excuse. It's a red herring. It's irrelevant to the issue. 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: David Miller on 5 Mar 2010 10:30 From: Daniel Stone <daniel(a)fooishbar.org> Date: Fri, 5 Mar 2010 17:17:54 +0200 > On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: >> If it effects such a large number of people, which this noveau thing >> does, it's entirely relevant to everyone. And the way it's breaking >> and making kernel development difficult for so many people matters to >> us. > > Maybe the lesson to be learned from all this is, 'if the developers > don't want something merged because they're not ready and forsee huge > problems in the future, actually listen to them instead of blindly > ramming it in regardless'? But maybe that's just me. That's doesn't work, and it never will. First of all, if we didn't merge the driver Fedora users wouldn't be able to test the upstream kernel at all. And if you think things through, there is one and onle one set of actions that would have made things work properly. And that's merge the driver upstream and not break user visible APIs. In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. Consider if it didn't go upstream and I want to do upstream kernel development, ok so I patch the noveau-of-the-moment into my upstream tree. Six months and 10 DRM library updates later I go back and try to boot that kernel. And it's not going to work. So if the user visible APIs are changed in any set of situations (upstream merged, not upstream merged, etc.) things can end up breaking. Ergo, you simply can't sanely do it at all. You have to have a compatability story when you change these things. Personally I wouldn't have ever committed to that "user visible APIs can break cause it's in -stable." Because that's complete garbage. -- 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: Daniel Stone on 5 Mar 2010 10:50 On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: > If it effects such a large number of people, which this noveau thing > does, it's entirely relevant to everyone. And the way it's breaking > and making kernel development difficult for so many people matters to > us. Maybe the lesson to be learned from all this is, 'if the developers don't want something merged because they're not ready and forsee huge problems in the future, actually listen to them instead of blindly ramming it in regardless'? But maybe that's just me. Cheers, Daniel
From: David Miller on 5 Mar 2010 10:50 From: Daniel Stone <daniel(a)fooishbar.org> Date: Fri, 5 Mar 2010 17:40:09 +0200 > 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. 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. 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. -- 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 10:50
> Personally I wouldn't have ever committed to that "user visible APIs > can break cause it's in -stable." Because that's complete garbage Staging has to have the no API rules. Read some of the stuff in there to understand why or apply about 30 seconds of thought to what it would mean to you. There are staging drivers using old wireless layers. If you say that no API can be broken from staging then you will have to put the old wireless compatibility into your network code forever. Does that fill you with joy, light and happiness ? Whether nouveau should ever have gone into staging is a different question. I don't personally think its all as clear cut as it might seem. Quite a few distributions ship whacky wireless drivers with old API's as the choice is that or nothing. They manage the user expectation and they deal with the drivers moving from one wireless stack to the other and mostly successfully hide it in userspace. The differences here appear to be - Having no video is more annoying than having no wireless - Userspace failed to hide it (so maybe its not a kernel ABI problem but a failure to anticipate the need for versioned libdrm and the importance in some eyes of supporting the kernel.org kernel - which like it or not is a corner case for distro *users*). - The box it broke happened to belong to Linus but that doesn't really require tantrums or fingerpointing to fix, particularly when its only the combination of a set of decisions and misunderstandings by Linus, Fedora and the Nouveau developers together that combined to create the mess. 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/ |