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: <alpine.LFD.2.00.1003041538380.3751@localhost.localdomain>
Date:	Thu, 4 Mar 2010 15:53:32 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...il.com>
cc:	Stephane Marchesin <stephane.marchesin@...il.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> 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.

The problem with "at this stage" is that the stage has apparently been 
on-going for several years. 

Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are 
you guys simply planning on never supporting F12 with 2.6.34?  I'd expect 
it to be a _major_ pain to have that whole hardcoded "X and kernel must 
always change in lockstep".

And the sad part is, it would be so nice if the X server would just dlopen 
the right thing automatically, so that the low-level driver wouldn't even 
need to care. It already does the whole "discover which driver to load" 
part, wouldn't it be nice if that code had automatic versioning too, and 
then a low-level driver really wouldn't have to care, everything would 
automatically do the right thing just when the version changes.

Of course, the distro would still have to make all the different versions 
of libdrm available to users, but now updating one wouldn't screw over the 
others. So if you had a known-good setup with nouveau-0.0.15, you could 
install a nouveau-0.0.16 thing and _know_ that it won't affect that 
previous install at all.

And yeah, I realize that those version numbers are "wrong". Normal library 
versioning rules about patchlevel not changing semantics are obviously 
broken here. But maybe the rules could even try to first start with the 
exact version, ie do a "driver-x.y.z.so" load, then a "driver-x.y.so" 
load, then a "driver-x.so" load and finally a "driver.so" load.

But I guess that nothing even does that drmGetVersion() until the nouveau 
driver has already been loaded. Which kind of forces the low-level drivers 
to do any such versioning on their own. 

But wouldn't it be nice if something like this was done at a higher level, 
so that the drivers really wouldn't even need to care?

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