Re: [Qemu-devel] [RFC PATCH v5 4/6] module: implement module loading function

[Alex Bligh]

--On 11 September 2013 08:06:20 -0700 Richard Henderson <address@hidden> 
wrote:


> If we want dependencies between modules, we may well need to get the
> dynamic linker involved with the search directory.  This would rule
> out any command-line, or monitor-line altering of the path.
>
> But it does suggest the default being DT_RUNPATH, overridable "near"
> the command-line via LD_RUN_PATH.

Not quite sure what you are suggesting here. DT_RUNPATH is an elf
tag IIRC. Not sure what LD_RUN_PATH does. LD_LIBRARY_PATH affects
more than just this.

If we are using the dynamic linker and DT_RUNPATH (which I believe
is in the executable) or the normal paths we WILL NEED proper API
versioning etc.; in this case (in the distro example I pulled out),
an upgrade to qemu making an API change will have different API
versioned libs and these can happily coexist, so no need for directories.

But are we really sufficiently stable for that? Any internal change
in API (as modules communicate using an internal API, not something
wrapped with opaque struct *) is going to result in a library major
version number change as far as I can see. That's going to play merry
hell with distributions.

Assuming we restrict this to load dependencies (as opposed to version
dependencies), I would have thought the way to go is
a) ensure that each build of qemu has ALL the modules available.
b) qemu and all its modules always look in the same place
c) that place can be changed at load time (as well as at compile
  time) to permit different versions of qemu to be around.

I think this can be done with dlopen() as follows:

 If filename contains a slash ("/"), then it is interpreted as a
 (relative or absolute) pathname.

This means no searching is done with DT_RPATH, DT_RUNPATH etc.

It later says:

 If the library has dependencies on other shared libraries, then these are
 also automatically loaded by the dynamic linker using the  same  rules.
 (This process may occur recursively, if those libraries in turn have
 dependencies, and so on.)

My dlopen() foo is insufficiently strong to know what happens if you
have dependencies AND specify an absolute or relative path (as opposed
to just a module name). In an ideal world it would just look in the
same directory and not elsewhere, in which case we can use the
scheme I suggested AND use dlopen() AND not worry about API versioning
(yet).

> I also wonder about the utility of the subdirectories above, as
> opposed to filename prefixes.

+1

--
Alex Bligh