0

Understanding the Linux Kernel says

The kernel has two key tasks to perform in managing modules. The first task is mak- ing sure the rest of the kernel can reach the module’s global symbols, such as the entry point to its main function. A module must also know the addresses of symbols in the kernel and in other modules. Thus, references are resolved once and for all when a module is linked. The second task consists of keeping track of the use of modules, so that no module is unloaded while another module or another part of the kernel is using it. A simple reference count keeps track of each module’s usage.

Is it correct that any shared library can be both dynamically linked (using LD_LIBRARY_PATH), and dynamically loaded (by dlopen(), dlsym() and dlclose())?

Is a module a shared library to the Linux kernel?

How does Linux kernel dynamically use a module? Is it by dynamic linking (using LD_LIBRARY_PATH), or dynamic loading (by dlopen(), dlsym() and dlclose())?

2

Is it correct that any shared library can be both dynamically linked (using LD_LIBRARY_PATH), and dynamically loaded (by dlopen(), dlsym() and dlclose())?

Yes. The difference is that dynamic linking is driven by the dynamic linker, and by the time the program starts (from the program author’s perspective), the libraries have been linked and all the symbols have been resolved; dynamic loading involves doing all that manually.

Is a module a shared library to the Linux kernel?

More or less, but the loading mechanisms are different. The dynamic linker, and libdl, are user-space only, they can’t be used in the kernel.

How does Linux kernel dynamically use a module? Is it by dynamically linking (using LD_LIBRARY_PATH), or dynamical loading (by dlopen(), dlsym() and dlclose())?

The kernel loads modules using load_module, which does all the work itself: loading the ELF object, mapping the required segments, performing all the relocations, etc. It also performs a few module-specific tasks: checking their license, hooking them into sysfs, calling their initialisation function...

load_module is accessed from user space using the init_module or finit_module system calls.

  • Thanks. (1) Is libdl the library which provides dlopen(), dlsym() and dlclose()? (2) Do the three do the same or similar work, dynamic linking, dynamic loading (dlopen(), dlsym() and dlclose()), and load_module ? – Tim Oct 17 '18 at 13:41
  • 1. Yes, libdl is the library which provides dlopen() etc. (See dlopen(3) which mentions -ldl.) 2. They perform similar work, at least in terms of processing relocations, which is the core of dynamic linking. As mentioned load_module does a fair amount more, relating to module-specific functionality. – Stephen Kitt Oct 17 '18 at 13:56
  • Thanks. Does dlopen() perform the work of dynamic linking, besides dynamic loading? If yes, does it perform the similar work of dynamic linking and static loading? Why do we need to call dlsym() after dlopen() in order to use a function defined in the shared library, instead of using the function directly just like when dynamic linking and static loading? – Tim Oct 17 '18 at 15:01
  • dlopen() performs full-blown dynamic linking on the loaded object and any dependencies; but it doesn’t rewrite GOT entries in the loading object, because there aren’t any — otherwise the library would be loaded by the dynamic linker. This also explains why you need to use dlsym(). What do you mean by static loading? – Stephen Kitt Oct 17 '18 at 15:27
  • Thanks. "static loading" is opposed to dynamic loading, and if I am correct, static loading means that loading the shared library at the time loading the executable which uses the shared library. Why "doesn’t rewrite GOT entries in the loading object, because there aren’t any" means "need to use dlsym()"? – Tim Oct 17 '18 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.