Lucas De Marchi [Thu, 12 Jan 2012 17:23:51 +0000 (15:23 -0200)]
modprobe: rework module removal without tree traversing
Just like the module insertion, module removal is remade.
The dependencies line that comes from modules.dep already contains all
the dependencies necessary to remove that module. Therefore modprobe
doesn't have to do the recursion between the modules in order to remove
it. All we have to do is to remove in order:
For the module being removed:
----------------------------
1. softdeps (in reverse order)
2. deps (in reverse order)
3. module
4. postdeps (in reverse order)
For any of the dependencies:
----------------------------
1. softdeps (in reverse order)
2. module
3. softdeps (in reverse order)
Lucas De Marchi [Thu, 12 Jan 2012 04:21:26 +0000 (02:21 -0200)]
modprobe: rework module insertion without tree traversing
The dependencies line that comes from modules.dep already contains all
the dependencies necessary to insert that module. Therefore modprobe
doesn't have to do the recursion between the modules in order to load a
module. All we have to do is to load in order:
For the module being loaded:
----------------------------
1. softdeps
2. deps
3. module
4. postdeps
For any of the dependencies:
----------------------------
Lucas De Marchi [Wed, 11 Jan 2012 20:29:55 +0000 (18:29 -0200)]
modprobe: break dependency loop by checking if module is loaded
modprobe doesn't have support for handling dependency loop. That happens
with poorly written softdeps that can introduce a loop. We must deal
with them like it's being done in libkmod.
However, we can break a dependency loop when the dependency was already
inserted. This commit fixes this issue, that happens in the following
scenario:
dependencies:
-------------
modA:
modB: modA
modC: modA
config:
softdep modA post: modB modC
This creates the following loop:
modA
inserted ok
handle post-soft-deps of modA -> modB modC
modB
handle dependencies of modB -> modA
modA is already inserted
handle post-soft-deps of modA -> modB modC
And so on and so forth.
Now we break the loop by checking if module is already inserted, before
handling it. Thus this gives us:
modA
inserted ok
handle post-soft-deps of modA -> modB modC
modB
handle dependencies of modB -> modA
modA is already inserted
inserted ok
modC
handle dependencies of modC -> modA
modA is already inserted
inserted ok
Lucas De Marchi [Tue, 10 Jan 2012 16:06:24 +0000 (14:06 -0200)]
build-sys: workaround libtool issue with argv[0]
Symlinking tools to kmod doesn't work because argv[0] is not the name of
the symlink, but rather 'kmod' (since libtool's wrapper script calls the
tools/.libs/kmod directly)
Now we create another binary kmod-nolib that is statically linked to
libkmod so we can call the binary directly and do not worry about
LD_LIBRARY_PATH.
Lucas De Marchi [Mon, 9 Jan 2012 06:20:55 +0000 (04:20 -0200)]
doc: add gtk-doc to generate documentation
Current limitation is horrible no support to sections: we have to to
have separate header files or to maintain the libkmod-sections.txt file.
We are doing the latter.
Lucas De Marchi [Sun, 8 Jan 2012 20:08:05 +0000 (18:08 -0200)]
modprobe: fix error path when loading dependencies
demarchi> scenario is the following:
demarchi> modA depends on modB and modC
demarchi> if there's a race when trying to insert a dependency of a module, say
modB, it will stop loading all the modules
demarchi> it should check by "module already loaded error"
demarchi> like it does for modA
Lucas De Marchi [Sun, 8 Jan 2012 03:02:29 +0000 (01:02 -0200)]
Replace NAME_MAX with PATH_MAX for module aliases
Module aliases can be bigger than NAME_MAX. So, replace with PATH_MAX
that is bigger enough to hold them.
Technically in some places NAME_MAX would be sufficient (those using
module names only), but they use functions that can be called with
alias. So increase the buffers in these cases to PATH_MAX too.
Refactor code to use pointer to functions, avoiding the previous
Now comp_types defines a magic header to be checked (size and bytes),
with the associated load() and unload() operations. If a header
matches, their operations are used. Otherwise the regular file
operations (mmap/munmap) are used.
File descriptor close is managed by the common code if it's valid
(>=0). If some code steals the file descriptor (eg: gzopen), then they
must change file->fd to -1.
This way the code should be easier to extend and avoid bugs.