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: Stephane Marchesin on 4 Mar 2010 18:20 On Thu, Mar 4, 2010 at 15:03, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > > On Thu, 4 Mar 2010, Adam Jackson wrote: > >> On Thu, 2010-03-04 at 11:14 -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. >> >> So unmerge it. > > That's what I told people I can do (I'd just revert that commit). > > I can do that. But it's not very productive, is it? What about the people > who _do_ want to run the rawhide tree? > > Seriously - what's wrong with my suggestion to just version things > properly? What's wrong with _fixing_ a stupid technical problem? What's > wrong with people that you can't see that there are actual _solutions_ to > the f*cking mess that is the current situation? > > I can solve it for my own use, and I already stated so. But while kernel > developers should be scratching their own itches, a kernel developer that > can't see past his own small sandbox is pretty damn worthless. We do need > to fix this - and I'm bringing it up and complaining about it, because the > nouveau people have _not_ done anything remotely sane. > Again, if we thought the DRM interfaces were good to begin with, we'd have submitted the driver for inclusion. But that's not the case so the we didn't submit the DRM. Whoever did gets to cope with the issues. Good luck, Stephane -- 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 18:30 On Thu, 4 Mar 2010, Linus Torvalds wrote: > > Is it really just nouveau? I've not looked, but I bet the intel driver and > the radeon driver have _exactly_ the same "oh, I'm the wrong version, I > will now kill myself" behavior. Ok, I cloned the drm tree just to see, and it does seem like it's just nouveau that does that whole thing. At least from a quick grep of drmGetVersion() calls. > I certainly seem to remember some similar issues with the intel driver > long long ago. ... but Jesse tells me that it's using feature masks etc, so maybe my recollection is about unrelated issues. So yeah, nouveau seems to "special". Although somebody already said that if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon driver just doesn't check the version number, and fails in different ways. 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: Michel Dänzer on 4 Mar 2010 18:30 On Thu, 2010-03-04 at 15:19 -0800, Linus Torvalds wrote: > > What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? Nothing. :) Only the major version is supposed to signify outright incompatibility, the minor version signifies backwards compatibility within the same major version, and the patchlevel has no impact on the interface. All the other drivers are basically following this, only nouveau is abusing the patchlevel as a major version for reasons beyond me. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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 18:30 On Fri, 5 Mar 2010, Dave Airlie wrote: > > Its nouveau project not X not DRM, stop generalising the situation. Is it really just nouveau? I've not looked, but I bet the intel driver and the radeon driver have _exactly_ the same "oh, I'm the wrong version, I will now kill myself" behavior. I certainly seem to remember some similar issues with the intel driver long long ago. What would happen if I changed DRIVER_PATCHLEVEL to 1 for the i915 driver? Would it try to handle it gracefully? Or are we in the same situation that the intel driver guys can never fix anything fundamental without doing a whole flag day? 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: Dave Airlie on 4 Mar 2010 18:40
On Fri, Mar 5, 2010 at 9:28 AM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > > On Thu, 4 Mar 2010, Linus Torvalds wrote: >> >> Is it really just nouveau? I've not looked, but I bet the intel driver and >> the radeon driver have _exactly_ the same "oh, I'm the wrong version, I >> will now kill myself" behavior. > > Ok, I cloned the drm tree just to see, and it does seem like it's just > nouveau that does that whole thing. At least from a quick grep of > drmGetVersion() calls. > >> I certainly seem to remember some similar issues with the intel driver >> long long ago. > > .. but Jesse tells me that it's using feature masks etc, so maybe my > recollection is about unrelated issues. > > So yeah, nouveau seems to "special". Although somebody already said that > if I'd have had a radeon, I'd have seen similar issues. Maybe the radeon > driver just doesn't check the version number, and fails in different ways. > As I mentioned earlier we had one issue with i810 about 7-8 years ago, before I was here, someone changed the i810_drm.h api incompatibly in XFree86. This was one of the things that led to having a proper policy. For radeon while we were developing the KMS feature in staging we changed the API once or twice, while we were developing KMS in Fedora we changed it at least 4 times, we shipped Intel KMS in F9 with a completly different API and just dealt with it, since upstreaming changed the API completely. The staging API changes were mostly to fix things that userspace did that made it possible to trample over other X users memory. This meant you had to bump the userspace that was doing the evil thing by mistake. Once we removed KMS from staging, we stabilised all APIs and behaviour (its not just the API, internal command stream checking for security issues). Since then we made one change to the CS behaviour in a backwards compatible manner so that old userspaces wouldn't die, but you couldn't abuse the hole they had relied on. I'm not saying it doesn't happen in other drivers from time to time, but when it does its treated as regression, for nouveau and STAGING that isn't what the Nouveau project (which Stephane mostly speaks for) seems to want at this stage. Dave. -- 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/ |