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
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
