From: Adam Jackson on
On Fri, 2010-03-05 at 06:24 -0500, Jeff Garzik wrote:
> On 03/04/2010 05:59 PM, Adam Jackson wrote:
> > in which you merely remove the nouveau userspace component, and in which
> > I can't tell if you built nouveau into the kernel or not, but I assume
> > you didn't based on your previous post. The X server does only try the
> > one driver before falling back to vesa, which is a bug in the fallback
> > logic I suppose. I've (blindly) fixed that for F13 now.
>
> Thanks. Can this be put into F12 too?

Sure, why not.

> > - you didn't try writing an xorg.conf fragment
> > - you did, and it didn't work anyway
> >
> > The latter case is entirely plausible, as nv is not the sort of driver
> > that gets a lot of love, but I'm not aware of any open bugs about gf980
0
> > in particular in nv.
>
> The latter... would modeset in grub interfere, perhaps?

It's not going to do anything if you didn't build a KMS driver. It's
just a kcmdline option like any other; if there's no module to honor it,
then it doesn't do anything. grub doesn't have any particular KMS
awareness.

I'm really going to have to see an X log and dmesg from the failure mode
when actually using nv to diagnose this any further.

- ajax
From: Luca Barbieri on
It seems to me that Linus' technical argument is indeed being mostly ignored.

While breaking the ABI is unfortunate, the real problem that Linus
complained about is that you can't install several userspace versions
side-by-side.

This means that if you install your new kernel and userspace, reboot,
and find the new kernel doesn't work for some reason, you can't just
go back to the old kernel and have working X, because you just
replaced userspace with a version that no longer works with the kernel
that worked correctly.

This is even worse for distributions that want to upgrade the kernel,
because each kernel package would need to have a Depends on the exact
userspace package version.
Thus, the package manager would remove the older kernel when the new
one is installed (since they depend on different versions of the same
userspace package).
If the new kernel somehow doesn't work, the user is totally screwed
and must reboot from a live CD.

As pointed out, in this case, it is relatively easy to solve by adding
a version number to libdrm-nouveau, the X driver and the DRI drivers.
X will then have to load the correct driver and give Mesa the DRI
driver name with the correct version appended.

It may be a good idea to do this before the new nouveau ABI gets
shipped in released distributions, and with a generic mechanisms that
can be used by all X/drm drivers.

Workarounds are possible, such as replacing /usr/bin/X with a script
that loads the correct version, or using X over /dev/fb0 (which should
work fine with any DRM KMS driver, and any non-DRI framebuffer), but
they shouldn't be needed.

BTW, the nVidia proprietary driver also ties the kernel and userspace
version in this way, and is actually worse because it replaces the X
libglx.so, breaking all other drivers.
--
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
From: Alan Cox <alan(a)lxorguk.ukuu.org.uk>
Date: Fri, 5 Mar 2010 16:02:17 +0000

>> You can't unleash something like this on a userbase of this magnitude
>> and then throw your hands up in the air and say "I'm not willing to
>> support this in a reasonable way."
>
> Not to belabour the obvious - they didn't. Linus ordered them to merge it.

And I'm arguing not merging it upstream would be like saying
the same thing.

>> We're better than that.
>
> If you consider the problem is with the Fedora kernel team decision to
> merge it into Fedora in the first place

For the second time Alan, I don't.

I think Fedora should have merged it.

I think it should be upstream.

And I think the API bustage needs to be avoided.

--
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, David Miller wrote:
>
> In fact, I argue that the moment nouveau went into Fedora and
> was turned on by default, the interfaces needed to be frozen.

Now, I agree that that would have been the optimal setup from a testing an
user standpoint, but I think it's a bit too strong.

Things don't need to be "frozen", but flag-days need to be avoided. The
problem with flag-days is not so much that they need new support code:
downloading a new version of something like X is not a huge issue. But
flag-days work both ways: it's not just that you have to download a new
version, it's that you can't go _back_ either - not even a little bit.

For example, I can now test my new kernel, but if it turns out that there
are problems with it, I'm now officially screwed. I can't go back and rely
on even the stable distro kernel, like I'm used to ("ok, that _really_
didn't work, but happily I didn't remove the distro kernel, so I'll just
reboot with that"). And I certainly can't bisect without major problems.

And Fedora can't install the new libraries, because they won't work with
their own old kernels either. So it effectively causes a version freeze:
it looks like F12 will simply _never_ be able to support a 2.6.34 kernel,
because if they do that, then everybody who gets the new packages (and has
a nvidia graphics card) will now be stuck.

So flag-days really are bad. They're bad for users, they're bad for
distributions, and they're eventually bad for developers too because now
they lose a lot of every-day testing. Some day, F13 will come out, and the
_only_ testing all the new code ever got was the (relatively small)
rawhide community, and the kernel crazies who did things manually.

But even if you can't guarantee backwards compatibility, if you avoid the
flag-day, and can have a new version of the environment that can handle
both the old and the new model, you _could_ install that on F12 (before
switching kernels), and not be in that effective version-freeze.

Yeah, you'll still have a dependency chain, but it will be a one-way one,
so you're not stuck. As long as you have the newest vesion of whatever
libraries or support, you can go back-and-forth and test development
systems.

And we do that for the kernel in many other respects. We require that you
have a "recent enough" compiler, for example. So there are already lots of
those one-way dependencies where we're not infinitely backwards compatible
with user space, but we've been pretty good at not having flag-days.

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: Alan Cox on
> You can't unleash something like this on a userbase of this magnitude
> and then throw your hands up in the air and say "I'm not willing to
> support this in a reasonable way."

Not to belabour the obvious - they didn't. Linus ordered them to merge it.

> We're better than that.

If you consider the problem is with the Fedora kernel team decision to
merge it into Fedora in the first place, perhaps you should have an
internal Red Hat discussion about it with the people who made that
decision - who I suspect see it differently. Either way the Nouveau
developers don't control Fedora packaging policy, in fact the GPL licence
specially ensures the control is not theirs.

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/