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 for Android: free password hash cracker in your pocket

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

Message-Id: <201003041924.02082.edt@aei.ca>
Date:	Thu, 4 Mar 2010 19:24:01 -0500
From:	Ed Tomlinson <edt@....ca>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dave Airlie <airlied@...il.com>,
	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 Thursday 04 March 2010 18:53:32 Linus Torvalds wrote:
> 
> 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?

Why not support a _minimal_ ABI that will always let X start with nouveau?
Having X working does not mean that all forms of acceleration have to 
work too.  If X starts, even if is slow, users can easily check logs which
should have a message saying 'ABI change - upgrade your ...'.

Thoughts?
Ed Tomlinson
--
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/