From: Linus Torvalds on


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


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
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
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


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/