linux-kernel - Re: [git pull] drm request 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20100305.072612.186421758.davem@davemloft.net>
Date:	Fri, 05 Mar 2010 07:26:12 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	daniel@...ishbar.org
Cc:	alan@...rguk.ukuu.org.uk, 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
Subject: Re: [git pull] drm request 3

From: Daniel Stone <daniel@...ishbar.org>
Date: Fri, 5 Mar 2010 17:17:54 +0200

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

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

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.

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

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

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/