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 11:50 On Fri, 5 Mar 2010, Alan Cox wrote: > > 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? > > So why are you screaming at the DRM and Nouveau people about the > breakage ? That's the bit I really don't understand. Umm. You _really_ haven't been following, have you? Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The guy who is, as far as I know, effectively in charge of that whole integration. Yeah, I realize that there are other people (Kyle?) involved, and maybe Dave isn't as central as I think he is, but I learnt from last time that the nouveau guys don't seem to care. And I would like to say that yes, Dave really helped me. He got me a working setup again. I thank you, Dave. It means I don't have to revert the thing, and we can hopefully make progress. That said, I do think that the Fedora people _should_ have been the ones to catch this as a problem, and pushed back a bit on the Nouveau people even before it got to me. For all the reasons I've mentioned. Even if you need to change the interface, I've actually looked at the patch in question (have you, Alan?), and I got the very strong feeling that it _could_ have been done without breaking compatibility so completely and utterly, and making it so apparently intentionally hard to have a driver that can handle both the old and the new. IOW, maybe it would have required a new nouveau_drv etc, but with a slightly less hack-and-slash approach, maybe the new one could have supported the old interfaces enough to at least limp along. For example, breaking DRM so that 3D doesn't work, but you still get basic 2D acceleration - that's _way_ more acceptable, and is likely to need a much smaller subset of the whole DRI functionality. It looks like nobody even tried. 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: tytso on 5 Mar 2010 11:50 On Fri, Mar 05, 2010 at 06:04:34PM +0200, Daniel Stone wrote: > > 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. No, that's not what people are saying. What people are saying is, "avoid flag days". Deprecate things over a 6-12 month time period. We have lots of really good interfaces for doing that. You say you don't want to do that? Then keep it to your self and don't get it dropped into popular distributions like Fedora or Ubuntu. You want a larger pool of testers? Great! The price you need to pay for that is to be able to do some kind of of ABI versioning so that you don't have "drop dead flag days". If you don't want to be a good citizen, then prepared to have people call you out for, well, not being a good OSS citizen. - Ted -- 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 12:10 > Look at who I screamed at. Dave Airlie. The guy who works for Red Hat. The > guy who is, as far as I know, effectively in charge of that whole > integration. Yeah, I realize that there are other people (Kyle?) involved, > and maybe Dave isn't as central as I think he is, but I learnt from last > time that the nouveau guys don't seem to care. Ok "screamed about" is perhaps better wording. Why should the Nouveau guys care ? You've forced their hand, you've demanded stuff they said they didn't want to do and then you've bitched about things they said they would do. Actually I think they've been quite restrained. I'd probably have proposed a licence change to make it only work on FreeBSD and Solaris given that treatment ;) > Even if you need to change the interface, I've actually looked at the > patch in question (have you, Alan?), Yes but I read it somewhat differently. Someone who never made a commitment to stability decided to do the logical thing. They deleted all the old broken interfaces, they cleaned up their ioctls numbering and they tided up afterwards. I read it as the action of someone who simply doesnt acknowledge that you have a right to control their development and is continuing to work in the way they intended. You can only see it as malicious if you assume they ever had some reason to keep compatibility or had promised it somewhere. Quite the reverse happened, and they never asked to be upstream in the first place. "But the fact is, at least from my standpoint, I'd really hope that anything I had written would be used in ways I asked people to" - Linus Torvalds, 2004 -- 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: tytso on 5 Mar 2010 12:20 On Fri, Mar 05, 2010 at 05:04:14PM +0000, Alan Cox wrote: > You can only see it as malicious if you assume they ever had some reason > to keep compatibility or had promised it somewhere. Quite the reverse > happened, and they never asked to be upstream in the first place. The reason why this thread is inspiring so much traffic is because it's fundamentally about community norms. There are plenty of things that are not illegal, but which are at the same time anti-social. For example, there are all sorts of rules, if you are a researcher, about experimenting on human subjects. Many of those restrictions aren't codified in law, but if you violate them, other researches will say that you are a bad person, a bad researcher, and refuse to associate with you. And you might well lose your funding in the future --- but it's not illegal. If we are only talking about obligations under the GPL, sure, no one violated copyright licenses. But what *did* happen is someone basically said, "I want to experiment on a whole bunch of users, but I don't want to spend the effort to do things in the right way. I want to take short cuts; I don't want to worry about the fact that it will be impossible to test kernels without pulling Frankenstein combinations of patches between Fedora 13 and Fedora 12." It's much like people who drill oil in the Artic Ocean, but use single-hulled tankers and then leave so much toxic spillage in their wake, but then say, "hey, the regulations said what we did was O.K. Go away; don't bother us." Distro's that want to have a good reputation need to have a higher standard than, "hey, it's allowed by the GPL." And maybe if we are sinking to the point where people are going to use "stable means ABI breakages are allowed", we need to change the rules, since people want to quote rules as opposed to just being good community members. If you want lots of testers, then you need to be treat the testers, and the other developers in our development community with respect. I think the real problem was that Fedora and the Neauveu community are acting incredibly selfishly. They only care about their narrow point of view, and don't care about the pain they are inflicting on the kernel development process and other kernel developers. This is _legal_. It is, however, anti-social. - Ted -- 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 12:30
On Fri, 5 Mar 2010, Daniel Stone wrote: > > 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? I think that's what David ended up saying, but I think he is being _too_ strict. It's not how we've done other things either. We've changed ABI's over time many times. And we've even had complete breakage of old tools (although that is very much reserved for system tools, not regular applications: I think we've been almost religious about "normal" apps not breaking, unless there was some really overriding reason like security that forced us to really remove some interface). But most of the changes have been extending things, leaving the old interfaces around (often as wrappers around the new internal world order, sometimes by effectively having actual duplicated code). And then the old interface is maintained for quite a while (sometimes decades, often years, and generally at least for several kernel versions so that people have time to upgrade, and a distro can generally pick a newer kernel without having to change anything else). Sometimes we've done things that really end up requiring new tools. It's pretty rare, but it does happen. It happens a lot more for "esoteric" things that aren't every-day-in-your-face (I've seen at least _one_ mutter about "sysfs" in this thread ;) and might break something like a temperature sensor, for example. So the machine might _work_ and you could go for days without even noticing, but you might have some very specific functionality missing. Maybe your power meter doesn't work, or maybe you need to upgrade your kernel profiler to get good profiles again. Things like that. I suspect you as an X person know this very well, in fact. X itself has carried along a _lot_ of cruft exactly like this, that you guys have been removing only in the last few years - sometimes after decades of it being there. The whole switch to modern font handling is an obvious example of a _major_ fundamental feature change like that. So in general, what the kernel strives for is that very kind of "the old model will still work - but it might be slow and emulated on top of a new way of dong things, and not get a lot of attention any more". And sometimes, there's really no good way of maintaining two interfaces at the kernel level, and then you have the downstream tools that have to learn to pick either the old or the new one, so that the tool still works regardless. And again, the old code _eventually_ bitrots or gets cleaned up, but what you really really want to avoid is to have a flag-day when you switch from one to the other, and you can't switch between adjacent versions of the kernel. In the 2.4.x/2.6.x split, for example, we did have system tools that needed to be upgraded if you came from a 2.4.x environment. You can still see signs of that in the kernel tree: we have that whole Documentation/Changes file that _still_ remains in our tree, even though it's purely historical. But if you look at that Documentation/Changes file, I don't think there is _any_ flag-day issue except for the removal of "devfs". People _still_ talk about devfs in hushed tones. Everything else is about having to upgrade system tools _before_ upgrading the kernel (iow, they still worked on 2.4.x, but you needed recent enough versions of them to compile and run a 2.6.x kernel). In other words, it wasn't a "flag day" (apart from the already mentioned devfs users, and possibly something else I can't think of). It was an upgrade, yes, and it required some other things to be recent, but you could go back-and-forth between kernels if you had to. (Of course, it's now many years since that, so maybe my rose-colored glasses makes me forget the pain involved. And I obviously personally never made the whole 2.4.x -> 2.6.x jump, since I'd been running the development kernels in between. So maybe I forgot some painful part). 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/ |