Ooops <blush> partially a false alarm. (modprobe was running the wrong
insmod) _but_ this resulted in an interesting error message. When
modprobe fails to load a module with dependencies it seems that modprobe
checks the module you are trying to load before it loads dependencies
(like it should) and if it fails it still tries to unload the
dependencies even though they were never loaded. (Feature or bug?)
root(bash):03:48:24 PM:~[2]#lsmod
Module Size Used by
psaux 2244 1
misc 852 1 [psaux]
root(bash):03:48:25 PM:~[2]#depmod -a
root(bash):03:48:34 PM:~[2]#modprobe sr_mod
kernel_version needed, but can't be found
cdrom: No such file or directory
^^^^^^^^^^^^^^^^^^^^^^^^
sr_mod dependency that was never loaded but it still is trying to unload
the cdrom module here.
TODO: Someone should fix this error message so that it says "module not
found" rather then the current message. The reason I know for a fact
that this an failed attempt at unloading this module is because I used
strace.
Also when I grepped the drivers in the kernel tree there appears to be
some small coding inconsistencies like for instance in drivers/net.
#find . -name \*.c -type f -print -exec grep kernel_version {} \;
[blah blah]
./drivers/net/sunhme.c
./drivers/net/smc9194.c
char kernel_version[] = UTS_RELEASE;
./drivers/net/a2065.c
./drivers/net/strip.c
[blah blah]
I'm curious if smc9194.c compiles correctly as a module. Or maybe this
driver has not been updated to 2.1.x memory management etc. There are
others of course.
Glenn Bily
Excerpts from mail: 24-Aug-97 Re: modutils-2.1.42 Richard
Henderson@cygnus (531*)
> > Anybody know what's up with the kernel_version variable or constant
> > rather? Seems that in some drivers (2.1.51 kernel) the variable is set
> > and most of the others it isn't.
> Really? I don't see that here. Which drivers? If you do
> objdump -s -j .modinfo driver.o
> do you not see something like
> Contents of section .modinfo:
> 0000 6b65726e 656c5f76 65727369 6f6e3d32 kernel_version=2 <<<<<<
> 0010 2e312e35 31000000 7573696e 675f6368 .1.51...using_ch
> 0020 65636b73 756d733d 31000000 00000000 ecksums=1.......
> r~