Bug 2138

part of the problem here is there's no way to change installed servers to do
something different.  probably what needs to happen on the IHV's side is to run
'X -version' in the install script and parse that for the server version number.

from 6.9 on, i can change this so that the server will prefer elfloader modules
if built with MakeDllModules NO; but there's no changing the behaviour of the
installed 6.7 and 6.8 userbase.  is there a better approach?

(In reply to comment #1)
> is there a better approach?

I don't see any. Installing the dlloader module for 6.9 or newer only sounds
quite manageable though.


BTW, you were right, I misremembered: it's actually the other way around, i.e.
the server loads the elfloader module even if the rest is dlloader. Changing bug
title accordingly.

Actually, the current preference for elfloader modules and the fact that this
will be fixed in 6.9 mean that we can just ship both versions whenever we are
ready to do so, and only pre-6.9 dlloader installations should break, which
should be relatively rare. So this seems fine.

the only really common dlloader use case for 6.8 is Gentoo, where they can key
off USE=dlloader to not install elfloader bits.  cc'ing spyderous for this
reason; when ati-drivers package starts shipping dlloader modules, the ebuild
will need to be dlloader-aware.

Created attachment 1687 [details] [review]
smarter-loader-search-behaviour-1.patch

this turns out not to be true.	sigh.

the libdl loader backend is _always_ built.  evidence: nvidia's libglx.so. 
MakeDllModules only affects the kind of modules the server builds.  in other
words, older server versions will always attempt to load dlloader modules
first.	so you really do have to check the server's version first, and/or
examine whether (say) libfb is a DSO or an ar archive.

attached patch changes the loader search pattern to be less stupid if the
server was built without MakeDllModules.  the heuristic is then:

- check server version
  - if >=6.9, install blindly
  - if < 6.9 or unknown, install what kind are already installed

Colour me confused. :( I put both foo_drv.so and foo_drv.o in a 6.8 tree that
otherwise only contained *.so modules, and it loaded foo_drv.o. Looking at the
source, I don't understand why. Any ideas? (Could it be that *.so is only
preferred if the executable bit is set or something?)

It looks like loadmod.c:FindModule() just does readdir(), and loops through the
directory entries looking for the first match.  This seems dependent on the
inode order.  I think rather than mucking with the stdPatterns[] array, you need
to alter the FindModule(), perhaps to assemble a list of all the entries in a
directory, and then search through that list multiple times with appropriate
priority (eg: first look for .so, then .o, etc).

Created attachment 1701 [details] [review]
smarter-loader-search-behaviour-1.patch

turns out this mirrors something daniels did while speeding up ubuntu's startup
time:

http://people.ubuntu.com/~daniels/xorg/028_loader_speed_hack.diff

that one's dlloader-only; this new patch extends it to be elfloader-aware.  not
even compile tested (yet), but you get the idea.

Isn't fp now superfluous?  Other than that, the patch looks good.

FWIW, a new version of #028 is up at the same URL that fixes a couple of minor
issues and also gets rid of the whole regexp thing altogether (although this
breaks LoaderListModules altogether; not that I care that much, but that's half
the reason I haven't bounced it upstream, the other half being that the loader
is so amazingly shit that we're best off just replacing it wholesale). 
Iterating over the extensions per ajax is a lot cleaner tho.

*** Bug 1806 has been marked as a duplicate of this bug. ***

Created attachment 2530 [details] [review]
smarter-loader-search-behaviour-3.patch

this one actually compiles, and adds a check for module names unadorned by lib
or _drv to match cirrus and nv submodules.

i'll boot-test this one shortly, if it works i'll commit.  snapshot users are
starting to get hit by this and i'mn tired of explaining the workaround.

applied to HEAD, closing.  thanks to all for the analysis!