Lucas De Marchi [Sat, 21 Jan 2012 17:38:25 +0000 (15:38 -0200)]
build-sys: do not create symlinks by default
Distro packagers should create them instead. It's too much trouble to
create them in the build system and every distro wants a different path
for them.
Lucas De Marchi [Sat, 21 Jan 2012 04:45:06 +0000 (02:45 -0200)]
modprobe: kill operations depending on path
It was not on module-init-tools and it doesn't make much sense. It will
deal with dependencies, but looking at modules in the index. This might
not be the module we want if we are loading another from outside of the
tree.
Dealing with paths causes this bug (supposing there's a module names
squashfs):
# cd /
# touch squashfs
# modprobe squashfs
That is because it detects that squashfs exists as a file and it will
try to load it instead of the alias "squashfs".
If you need to load a module from a path, use insmod.
Thanks to Silvan Calarco <silvan.calarco@mambasoft.it> who reported the
bug and helped debugging it.
Lucas De Marchi [Tue, 17 Jan 2012 14:10:42 +0000 (12:10 -0200)]
Check if struct stat has mtim member
Not all libc's have a mtim member in struct stat (dietlibc doesn't).
Change ts_usec() to receive a struct stat as parameter and implement it
accordingly for both cases.
Lucas De Marchi [Tue, 17 Jan 2012 12:05:02 +0000 (10:05 -0200)]
modprobe: flush stdout before dumping indexes
Index dump doesn't use stdio.h function and instead call write()
directly on STDOUT_FILENO file descriptor. Therefore we need to flush
stdio buffers before calling it, to be sure the configuration dump will
appear before index's.
Lucas De Marchi [Mon, 16 Jan 2012 17:56:17 +0000 (15:56 -0200)]
libkmod: dump index files
Provide a function to dump the index files to a certain fd. It could be
more optimized (particularly the functions to dump the index that were
copied and pasted from m-i-t), but it seems like the only user of it is
'modprobe -c', used for debugging purposes. So, keep it as is.
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.