Bug 2138 - Loader module type preference undefined
Summary: Loader module type preference undefined
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/DDX/Xorg/dlloader (show other bugs)
Version: git
Hardware: Other Linux (All)
: high normal
Assignee: Adam Jackson
QA Contact:
: 1806 (view as bug list)
Depends on:
Reported: 2004-12-22 21:40 UTC by Michel Dänzer
Modified: 2005-04-24 00:26 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

smarter-loader-search-behaviour-1.patch (928 bytes, patch)
2005-01-15 15:28 UTC, Adam Jackson
no flags Details | Splinter Review
smarter-loader-search-behaviour-1.patch (2.85 KB, patch)
2005-01-17 21:45 UTC, Adam Jackson
no flags Details | Splinter Review
smarter-loader-search-behaviour-3.patch (3.29 KB, patch)
2005-04-24 13:16 UTC, Adam Jackson
no flags Details | Splinter Review

Description Michel Dänzer 2004-12-22 21:40:03 UTC
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.
Comment 1 Adam Jackson 2005-01-14 11:42:09 UTC
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?
Comment 2 Michel Dänzer 2005-01-14 12:41:26 UTC
(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.
Comment 3 Michel Dänzer 2005-01-14 12:45:08 UTC
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.
Comment 4 Adam Jackson 2005-01-14 13:41:59 UTC
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.
Comment 5 Adam Jackson 2005-01-15 15:28:21 UTC
Created attachment 1687 [details] [review]

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
Comment 6 Michel Dänzer 2005-01-15 15:46:46 UTC
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?)
Comment 7 Andy Ritger 2005-01-17 13:19:46 UTC
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).
Comment 8 Adam Jackson 2005-01-17 21:45:37 UTC
Created attachment 1701 [details] [review]

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


that one's dlloader-only; this new patch extends it to be elfloader-aware.  not
even compile tested (yet), but you get the idea.
Comment 9 Daniel Stone 2005-01-17 22:47:37 UTC
Isn't fp now superfluous?  Other than that, the patch looks good.
Comment 10 Daniel Stone 2005-01-17 22:53:36 UTC
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.
Comment 11 Adam Jackson 2005-03-26 11:46:39 UTC
*** Bug 1806 has been marked as a duplicate of this bug. ***
Comment 12 Adam Jackson 2005-04-24 13:16:04 UTC
Created attachment 2530 [details] [review]

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.
Comment 13 Adam Jackson 2005-04-24 17:26:12 UTC
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.