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: Luc Verhaegen on 5 Mar 2010 09:00 On Fri, Mar 05, 2010 at 08:44:07AM +0100, Ingo Molnar wrote: > > Yeah. I've seen a few other bad arguments as well: > > 'exploding test matrix' > > This is often the result of _another_ bad technical decision: > over-modularization. > > Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature: > > - it's developed by the same tightly knit developer base who often cross > between these packages. Features often need changes in each component. > > - a developer to be able to do real work has to have the latest sources > of all these components. > > - a user just uses whatever horizontal version cut the distro did and never > truly 'mixes' these components as a conscious decision. > > - distros just try to get the latest and most capable but still stable > version. Desperately so. Often they will create a version mix that was > never tested by developers in that form. They'll expose users to ABI > combinations that were never really intended. They have trouble > bootstrapping and stabilizing those essentially random combinations and > then have trouble applying stability and security fixes. > > The thing is, if development has such characteristics then it's pretty clearly > not 3-4 separate projects but _one_ abstract project. [*] > > So the 'exploding test matrix' is simply the result of: creating ABIs between > 3-4 _artificial components of the same project_ and then going through > developer hell living with that mistake. [**] > > It's a bit as if we split up the kernel into 'microkernel' components, did a > VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and > then tried to develop them as separate components. > > If we did then then Linux kernel development would slow down massively while > in reality everyone would _still_ have to have the latest and greatest source > checked out to do some real development work and to be able to implement > features that affect the whole kernel ... > > Linux would become an epic fail of historic proportions if we ever did that. > > Ingo > > [*] I realize that it's possibly hard for Xorg to merge with mesa and the > kernel for license reasons, but my technical observation still stands. > > [**] I realize that modularization and many small packages were a clear > advantage when we were still all downloading bits via 14.4k modems, but > in this day and age of megabit connections that has become a non-issue. > Rampant over-modularization and the resulting loss of focus on the end > result (and the resulting explosion of a test matrix) is hurting us _far > more_ than the disadvantages of any monolithic could ever hurt. We are > seeing the proof of that all day with a 10+ MLOC kernel. Tying kernel, libdrm, X and mesa together 1-1 is not going to help anybody. When thinking along the same line of your reasoning, the answer is unifying graphics driver stacks, which requires increased modularization (in libdrm and mesa): one big abstract project. All of X.org, libdrm, drm, mesa/dri, mesa/gallium, all have relatively stable interfaces as they are supposed to support multiple (from 3 (libdrm) to ~50 (Xorg)) drivers. It's driver internal interfaces that are highly volatile, as it is easy to adjust all parts inside the same graphics driver stack, especially since the same developers know all these parts and it supports the same hw. On top, graphics driver are special, they are as complex and diverse as the hardware. So, graphics driver stacks can currently have up to 7-8 pieces spread everywhere: kernel drm driver, firmware, libdrm driver, Xorg driver, 2 mesa drivers, 1-2 media acceleration libraries. All spreading inherently unstable interfaces everywhere. Graphics drivers will always be complex, and buggy and unstable, but we should try to encapsulate some of that mess in a way that makes sense. I had a talk on FOSDEM about this which was very "warmly" received by some; the slides are here http://www.phoronix.com/scan.php?page=article&item=fosdem_2010_unification&num=1 Luc Verhaegen. -- 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 09:40 From: Alan Cox <alan(a)lxorguk.ukuu.org.uk> Date: Fri, 5 Mar 2010 12:38:34 +0000 >> The conclusion is crystal clear, breaking an ABI via a "flag day" >> cleanup/feature/etc is: > > Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor > junk that is in there being cleaned up it would be *insane* to keep their > old APIs > > See there's a bigger offence than breaking an ABI - its called not RTFM. All of this RTFM and what directory the noveau driver is sitting in is entirely irrelevant Alan. 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. It's about the tester base, and this breakage shrinks the tester base considerably. Or do you want the kernel tested by less people? -- 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: Mike Galbraith on 5 Mar 2010 09:50 On Fri, 2010-03-05 at 06:37 -0800, David Miller wrote: > From: Alan Cox <alan(a)lxorguk.ukuu.org.uk> > Date: Fri, 5 Mar 2010 12:38:34 +0000 > > >> The conclusion is crystal clear, breaking an ABI via a "flag day" > >> cleanup/feature/etc is: > > > > Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor > > junk that is in there being cleaned up it would be *insane* to keep their > > old APIs > > > > See there's a bigger offence than breaking an ABI - its called not RTFM. > > All of this RTFM and what directory the noveau driver is sitting in is > entirely irrelevant Alan. > > 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. > > It's about the tester base, and this breakage shrinks the tester base > considerably. > > Or do you want the kernel tested by less people? On the bright side, all this hubbub sends a very positive message to the noveau development crew. Folks, your work is important. I'd be proud as a peacock :) -Mike -- 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:10 > 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. > > It's about the tester base, and this breakage shrinks the tester base > considerably. > > Or do you want the kernel tested by less people? I think you miss a bigger picture ? If Fedora hadn't merged it then it wouldn't have gotten to the state of usability it had. If Fedora hadn't merged it then several hundred thousand users wouldn't have had useful working machines. So - do you want Linux used by a lot less people, and to have no Nvidia driver ? See - its all about viewpoints. Do you think screaming at people who did no wrong increases the kernel developer and testing base ? No I thought not. To be honest the big thing I object to here is certain people who should know better behaving like small children. Not just in the sense of throwing their toys around because mummy didn't buy them the right sweetie but in not thinking about how other people see the problem and their actions. - Fedora merged the stuff to make it work and to improve life for lots of users. Good intent, rational logical behaviour - Linus asked for it to be merged and was warned about the ABI. He did that for good, sound reasons. - The developers accepted the merge to staging so they could fix the ABI later, they made that clear - again all good sound intentions - The ABI change and clean up was done - again good sound intentions, rational behaviour - Linus then threw a tantrum. He's right there are issues about how user migration should be handled but he didn't need to go screaming at the DRM people (not their fault), Fedora (who had good sensible goals in what they did) or the Nouveau people (who told him what was going on well in advance and did exactly what was asked of them before) Firstly he's being hypocritical (he keeps saying he doesn't want to control distributions, he even refused to allow ext2 to be merged *until* Red Hat shipped it), he was told clearly, and staging is for unfixed ABIs. Secondly he's shouting at people who all did a right thing, which only produces bad feelings. All that was needed was a "Hey guys, I know its in staging but this is going to be a problem, can we either fix back compatibility or have some kind of migration policy and the tools so I can test it - otherwise I can't merge this" No blaming, no tantrums, no judgemental comments from a single viewpoint. A collection of good intentions produced a problem. It happens all the time, screaming and blaming may be how politicians sometimes behave but we can surely do better ? 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: David Miller on 5 Mar 2010 10:20
From: Alan Cox <alan(a)lxorguk.ukuu.org.uk> Date: Fri, 5 Mar 2010 15:09:34 +0000 > I think you miss a bigger picture ? > > If Fedora hadn't merged it then it wouldn't have gotten to the state of > usability it had. If Fedora hadn't merged it then several hundred > thousand users wouldn't have had useful working machines. I think Fedora were right to merge it, and I think it was proper to merge it into the upstream kernel. But I also think the large size of that userbase should have been respected by "doing the right thing" here, and that means not making it so hard for Fedora users to use upstream kernels out of the box. Making the "sandbox" claim cuts both ways 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/ |