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 4 Mar 2010 19:00 On Fri, 5 Mar 2010, Dave Airlie wrote: > > 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. The problem with "at this stage" is that the stage has apparently been on-going for several years. Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are you guys simply planning on never supporting F12 with 2.6.34? I'd expect it to be a _major_ pain to have that whole hardcoded "X and kernel must always change in lockstep". And the sad part is, it would be so nice if the X server would just dlopen the right thing automatically, so that the low-level driver wouldn't even need to care. It already does the whole "discover which driver to load" part, wouldn't it be nice if that code had automatic versioning too, and then a low-level driver really wouldn't have to care, everything would automatically do the right thing just when the version changes. Of course, the distro would still have to make all the different versions of libdrm available to users, but now updating one wouldn't screw over the others. So if you had a known-good setup with nouveau-0.0.15, you could install a nouveau-0.0.16 thing and _know_ that it won't affect that previous install at all. And yeah, I realize that those version numbers are "wrong". Normal library versioning rules about patchlevel not changing semantics are obviously broken here. But maybe the rules could even try to first start with the exact version, ie do a "driver-x.y.z.so" load, then a "driver-x.y.so" load, then a "driver-x.so" load and finally a "driver.so" load. But I guess that nothing even does that drmGetVersion() until the nouveau driver has already been loaded. Which kind of forces the low-level drivers to do any such versioning on their own. But wouldn't it be nice if something like this was done at a higher level, so that the drivers really wouldn't even need to care? 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: Linus Torvalds on 4 Mar 2010 19:10 On Fri, 5 Mar 2010, Dave Airlie wrote: > > Speaking as distro maintainer here, > > No because we've got versioned interfaces and we are happy to support them > yes it would be nice sometimes to dream about this, but its a major explosion in > the testing matrix. You have to realise the more codepaths a distro ships, the > more codepath it has to keep track off for security issues, for bug fixes, etc. I think you're missing the whole point here. There's no new and complex "testing matrix". You only ever test the newest version, so there's no additional testing. Here's the "inductive proof": - if the version number doesn't change, you aren't doing anything that is at all different from what you already do. - if the version number _does_ change, it does so only because you updated both the kernel component and the libdrm component together, and you test them together - exactly like you already do. So there is absolutely no difference for you. In either case, you only ever test paired up versions. If you make a new version, it will never _ever_ interact with old versions. There's no new complex testing needed. The only thing it allows is for you to have multiple kernels installed simultaneously - and be able to _use_ them all. Which is something you already do. And which the current model doesn't allow for. You may have three different kernels installed, but if libdrm got updated with a version change, only one of those kernels will actually _work_. > When to we decide to stop shipping nouveau_drv-0.0.13? when do we find > out it has a security issue? Irrelevant and total red herring. You never care about older versions, since if people have updated, they are running the newer version. So the older versions are there purely so that you _can_ have multiple different kernels, and so that your _developers_ can compile new kernels for older distributions. They aren't relevant for the case you point to: if somebody is just doing "yum update", they'll get - and use - the newer version anyway. > Here's the thing, distros are trying to ship an OS with a consistent set > of packages, not a pick-n-mix. But here's the thing: if you expect people to do development, they _need_ to be able to mix things. A kernel developer needs to be able to update their kernel. And a kernel _tester_ needs to be able to test that kernel. Seriously: what do you expect me to do right now in my situation? I'm not going to release a kernel that I can't test. So if I can't get a libdrm that works in my F12 environment, I will _have_ to revert that patch that you asked me to merge. Really. Look at it from my standpoint. Look at it from _any_ kernel developer standpoint. It would be totally irresponsible of me to release 2.6.34 without even eating my own dog-food on my own main machine. Can't you see that this is obviously true? So right now, I'm running with that patch reverted on that machine. I haven't committed the revert, and quite frankly, I'd really prefer not to. But the only way that "not revert" case can really happen is if there is some other way for me to have a working machine again. Think about it. Tell me what the solution is. 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: Ed Tomlinson on 4 Mar 2010 19:30 On Thursday 04 March 2010 18:53:32 Linus Torvalds wrote: > > On Fri, 5 Mar 2010, Dave Airlie wrote: > > > > 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. > > The problem with "at this stage" is that the stage has apparently been > on-going for several years. > > Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are > you guys simply planning on never supporting F12 with 2.6.34? I'd expect > it to be a _major_ pain to have that whole hardcoded "X and kernel must > always change in lockstep". > > And the sad part is, it would be so nice if the X server would just dlopen > the right thing automatically, so that the low-level driver wouldn't even > need to care. It already does the whole "discover which driver to load" > part, wouldn't it be nice if that code had automatic versioning too, and > then a low-level driver really wouldn't have to care, everything would > automatically do the right thing just when the version changes. > > Of course, the distro would still have to make all the different versions > of libdrm available to users, but now updating one wouldn't screw over the > others. So if you had a known-good setup with nouveau-0.0.15, you could > install a nouveau-0.0.16 thing and _know_ that it won't affect that > previous install at all. > > And yeah, I realize that those version numbers are "wrong". Normal library > versioning rules about patchlevel not changing semantics are obviously > broken here. But maybe the rules could even try to first start with the > exact version, ie do a "driver-x.y.z.so" load, then a "driver-x.y.so" > load, then a "driver-x.so" load and finally a "driver.so" load. > > But I guess that nothing even does that drmGetVersion() until the nouveau > driver has already been loaded. Which kind of forces the low-level drivers > to do any such versioning on their own. > > But wouldn't it be nice if something like this was done at a higher level, > so that the drivers really wouldn't even need to care? Why not support a _minimal_ ABI that will always let X start with nouveau? Having X working does not mean that all forms of acceleration have to work too. If X starts, even if is slow, users can easily check logs which should have a message saying 'ABI change - upgrade your ...'. Thoughts? Ed Tomlinson -- 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: Ben Skeggs on 4 Mar 2010 19:40 On Thu, 2010-03-04 at 16:08 -0800, Linus Torvalds wrote: > > On Fri, 5 Mar 2010, Dave Airlie wrote: > > > > Speaking as distro maintainer here, > > > > No because we've got versioned interfaces and we are happy to support them > > yes it would be nice sometimes to dream about this, but its a major explosion in > > the testing matrix. You have to realise the more codepaths a distro ships, the > > more codepath it has to keep track off for security issues, for bug fixes, etc. > > I think you're missing the whole point here. There's no new and complex > "testing matrix". You only ever test the newest version, so there's no > additional testing. > > Here's the "inductive proof": > > - if the version number doesn't change, you aren't doing anything that is > at all different from what you already do. > > - if the version number _does_ change, it does so only because you > updated both the kernel component and the libdrm component together, > and you test them together - exactly like you already do. > > So there is absolutely no difference for you. In either case, you only > ever test paired up versions. If you make a new version, it will never > _ever_ interact with old versions. There's no new complex testing needed. > > The only thing it allows is for you to have multiple kernels installed > simultaneously - and be able to _use_ them all. Which is something you > already do. > > And which the current model doesn't allow for. You may have three > different kernels installed, but if libdrm got updated with a version > change, only one of those kernels will actually _work_. > > > When to we decide to stop shipping nouveau_drv-0.0.13? when do we find > > out it has a security issue? > > Irrelevant and total red herring. You never care about older versions, > since if people have updated, they are running the newer version. > > So the older versions are there purely so that you _can_ have multiple > different kernels, and so that your _developers_ can compile new kernels > for older distributions. They aren't relevant for the case you point to: > if somebody is just doing "yum update", they'll get - and use - the newer > version anyway. > > > Here's the thing, distros are trying to ship an OS with a consistent set > > of packages, not a pick-n-mix. > > But here's the thing: if you expect people to do development, they _need_ > to be able to mix things. A kernel developer needs to be able to update > their kernel. And a kernel _tester_ needs to be able to test that kernel. Here's the thing. *You* pushed for nouveau to go into staging before any of the developers were ready for it. Two of the big reasons (from my POV) for not requesting inclusion were the context programs (which have since been dealt with) and that yes, we have no intention of keeping crusty APIs around when they aren't what we require. The idea of staging was to allow for exactly the second problem, so why are you surprised? The fact Fedora ships nouveau is irrelevant, we also expect that for the most part people will be using our packages, which deal with the ABI issues. > > Seriously: what do you expect me to do right now in my situation? > > I'm not going to release a kernel that I can't test. So if I can't get a > libdrm that works in my F12 environment, I will _have_ to revert that > patch that you asked me to merge. The F13 packages *will* work, so long as you're not bisecting back and forth. > > Really. Look at it from my standpoint. Look at it from _any_ kernel > developer standpoint. It would be totally irresponsible of me to release > 2.6.34 without even eating my own dog-food on my own main machine. Can't > you see that this is obviously true? With the release of 2.6.34 it'll require people to update userspace *once*, if they're rolling their own kernels and not using distro provided packages they should be able to handle that much. I agree it's a pain to bisect through, really. But it's far far from the common use case. Ben. > > So right now, I'm running with that patch reverted on that machine. I > haven't committed the revert, and quite frankly, I'd really prefer not to. > But the only way that "not revert" case can really happen is if there is > some other way for me to have a working machine again. > > Think about it. Tell me what the solution is. > > Linus > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel -- 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 19:50
On Fri, 5 Mar 2010, Ben Skeggs wrote: > > The idea of staging was to allow for exactly the second problem, so why > are you surprised? The fact Fedora ships nouveau is irrelevant, we also > expect that for the most part people will be using our packages, which > deal with the ABI issues. The fact that Fedora ships nouveau is _not_ irrelevant. That fact was what made it so important to get it merged. The distro rules wrt the kernel have been (for _years_ - before nouveau was ever even used by Fedora) that whole "upstream first". I don't understand how you can even call it irrelevant. The very fact that Fedora started using Nouveau was - and is - the whole reason for this issue. > > I'm not going to release a kernel that I can't test. So if I can't get a > > libdrm that works in my F12 environment, I will _have_ to revert that > > patch that you asked me to merge. > > The F13 packages *will* work, so long as you're not bisecting back and > forth. How do I install just the F13 libdrm thing, without changing everything else? I'm willing to try. We can make it part of the 2.6.34 release notes. And if we end up having people bisecting back and forth, I will hate that f*cking nouveau driver even more. 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/ |