If a module is present in both elfloader and dlloader versions, the loader always seems to try loading the dlloader one, even if all the other modules are only available in elfloader format. This makes it impossible for IHVs to just deploy both types of modules and have it just work no matter what type of modules the X installation uses.
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!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.