From: Stephane Marchesin on
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


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


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