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]

Date:	Fri, 5 Mar 2010 12:21:29 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3

On Thu, 04 Mar 2010 14:32:02 -0500
Jeff Garzik <jeff@...zik.org> wrote:

> On 03/04/2010 02:04 PM, Matthew Garrett wrote:
> > "Please note that these drivers are under heavy development, may or may
> > not work, and may contain userspace interfaces that most likely will be
> > changed in the near future."
> 
> Shipping it as the default Fedora driver for NVIDIA hardware makes that 
> text largely irrelevant.

Why ? Fedora isn't special, Fedora is just a distribution that uses the
Linux kernel. If Fedora turns on staging drivers then Fedora has to
accept that stuff breaks and manage that expectation with its users.
Staging is not and has not been API stable. If staging is going to be API
stable then it it useless and may as well be deleted.

In this case Linus is just a random Fedora user having a distro problem.
I don't even see what it has to do with linux-kernel. The libdrm problem
and difficulty using Fedora libdrm with current upstream kernel is a
Fedora problem not a kernel problem.

The kernel staging tree is unstable for API. Whether thats the Nouveau
guys breaking Fedora, submissions to network drivers breaking/removing
bogus APIs in stuff being cleaned up - whatever then thats how the cookie
crumbles. DRM has just made it all horribly more visible because the
libdrm/kernel stuff has such a complex and closely tied interface.

Serious discussion point perhaps should be: is the libdrm so close to the
kernel it ought to be in the same git tree ? Alternatively does it need
to be easier to have multiple Nouveau libdrms autoselected according to
the kernel side versioning. ELF library versioning is not rocket science
and both the old and new libraries exist and can be installed so all the
bits are present except for the wrapper to load the right sublibrary yes ?

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