Date:	Fri, 5 Mar 2010 17:40:09 +0200
From:	Daniel Stone <daniel@...ishbar.org>
To:	David Miller <davem@...emloft.net>
Cc:	skeggsb@...il.com, airlied@...ux.ie, linux-kernel@...r.kernel.org,
	jbarnes@...tuousgeek.org, dri-devel@...ts.sf.net, mingo@...e.hu,
	torvalds@...ux-foundation.org, alan@...rguk.ukuu.org.uk
Subject: Re: [git pull] drm request 3

Hi,

On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
> From: Daniel Stone <daniel@...ishbar.org>
> > On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
> >> If it effects such a large number of people, which this noveau thing
> >> does, it's entirely relevant to everyone.  And the way it's breaking
> >> and making kernel development difficult for so many people matters to
> >> us.
> > 
> > Maybe the lesson to be learned from all this is, 'if the developers
> > don't want something merged because they're not ready and forsee huge
> > problems in the future, actually listen to them instead of blindly
> > ramming it in regardless'? But maybe that's just me.
> 
> That's doesn't work, and it never will.
> 
> First of all, if we didn't merge the driver Fedora users wouldn't be
> able to test the upstream kernel at all.
> 
> And if you think things through, there is one and onle one set of
> actions that would have made things work properly.
> 
> And that's merge the driver upstream and not break user visible APIs.

Ah, argument by assertion.  That's my most favourite thing to deal with
on a Friday evening.

Wait, did I say 'most'? I meant least.

> In fact, I argue that the moment nouveau went into Fedora and
> was turned on by default, the interfaces needed to be frozen.

That's a matter for the Fedora kernel team; for better or worse, they
made the choices they did, which included going through all the relevant
pain to support this.  They didn't consider it suitable for upstream
because they didn't think everyone else should be forced to endure that
pain.

Now it's upstream and everyone's being forced to deal with it.  Great.

> Consider if it didn't go upstream and I want to do upstream
> kernel development, ok so I patch the noveau-of-the-moment into
> my upstream tree.
> 
> Six months and 10 DRM library updates later I go back and try to boot
> that kernel.  And it's not going to work.

nouveau isn't going to work, no.  vesa and nv remain unaffected; it's
not like it's some kind of catastrophic failure whereby booting it eats
your disk and gropes your sister-in-law.

> So if the user visible APIs are changed in any set of situations
> (upstream merged, not upstream merged, etc.) things can end up
> breaking.

Correct!

> Ergo, you simply can't sanely do it at all.  You have to have
> a compatability story when you change these things.

You cannot sanely do it at all in an upstream kernel, no.

> Personally I wouldn't have ever committed to that "user visible APIs
> can break cause it's in -stable."  Because that's complete garbage.

I guess you mean staging here; either way, that's a matter for you guys
to deal with.  I guess the upshot here is 'if you merge something
against the developers' wishes by screaming at them until they comply,
they repeatedly tell you that it's not API-stable, you merge it, and it
changes API, then joke's on you'.  If the result of this ridiculous mess
is that anything merged to staging is never allowed to change userspace
ABI ever, then great.  As I said, it's really not my problem.

Either way, fuck it, it's Friday.  To the pub.

Cheers,
Daniel

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists