The subject I used back then was like
"devfs: "cd" device not showing up initially.
Doug Gilbert was kind enough to explain to me
that the module loading needed be done explicitly
for sr_mod so that "cd" entries were registered by
devfs/devfsd. Then I came to wonder why
"generic" registeted by the module sg showed up.
I thought that I was not calling for automatic loading
of "sg" myself.
After a bit of exchange, Doug even went so far as to read
my config files to check for obvious mistakes, and we
could not find one.
It took me a while to figure out why "sg" was inserted
automatically.
The cause had nothing to do with devfs/devfsd interaction.
I found the answer today.
Short answer:
On my Debian GNU/Linux PC,
/etc/rcS.d/S20modutils (a symlink to /etc/init.d/modutils )
calls modprobe to install modules listed in
a file called /etc/modules at boot time,
and "sg" was listed there.
(I don't know / have forgotten why "sg" is listed there.)
I didn't realize that Debian uses this /etc/modules file as part
of its grand module configuration scheme.
(Or I have forgotten about this completely.)
--- somewhat longer description.
I followed the suggestions given by various
parties after my post, and when I inserted the
printk() inside a few scsi-related modules as
suggested by Doug Gilbert, the problem became immediately apparent.
The module "sg" was inserted by "modprobe", which in
turn was called from "S20modutils".
(swapon had nothing to do with the "sg" loading as I recently suspected.)
[I was going to insert "echo this is $0 or something to that effect in all of the
init script files to see where the sg loading was taking place, but
embedding the printk in a few C source files was easiter and so I tried it first.]
After seeing the message in dmesg output (now I use 128KB buffer
for printk to capture all the devfs/devfsd interaction debug messages),
I had to read /etc/init.d/S20modutils to find out why.
It turns out the Debian module init script uses /etc/modules
to list kernel module names that need to be inserted at boot up time.
And, for reasons unknown to me (now), the name "sg" was there (!).
I should have realized that something was amiss when
lsmod showed unused modules as in
tmscsim 29920 0 (unused)
sg 25728 0 (unused)
nls_cp437 4384 0 (unused)
hpfs 69216 0 (unused)
tmscsim is where the CD changer is located.
Until I manually mount a CD in there, the
module is unused. But what about other threes?
Forgetting about "sg", I had a nagging suspition
especially about the last two entries.
Why are they loaded at all? I could not figure
out why until today. These are also listed
in /etc/modules, and "auto" is not given.
So kerneld is not started at boot time...
FYO, just to show what the lsmod output looks like after
mounting a CD in nakamichi changer.
>duron:/home/ishikawa# mount /dev/scsi/host1/bus0/target6/lun0/cd /mnt2
>mount: special device /dev/scsi/host1/bus0/target6/lun0/cd does not exist
(* Oops I have forgotten the manual loading of sr_mod.o *)
>duron:/home/ishikawa# mkdir /mnt2
>mkdir: cannot create directory `/mnt2': File exists
>duron:/home/ishikawa# modprobe sr_mod
>duron:/home/ishikawa# mount /dev/scsi/host1/bus0/target6/lun0/cd /mnt2
>mount: block device /dev/scsi/host1/bus0/target6/lun0/cd is write-protected, mounting read-only
>duron:/home/ishikawa# lsmod
>Module Size Used by
>isofs 19280 1 (autoclean)
>sr_mod 13200 1
>cdrom 26912 0 [sr_mod]
>tmscsim 29920 1
>sg 25728 0 (unused)
>nls_cp437 4384 0 (unused)
>hpfs 69216 0 (unused)
>duron:/home/ishikawa# ls /mnt2
>Copyright Solaris_2.7
>duron:/home/ishikawa#
This final answer that I am posting today only shows that I have been using
module loading under linux for quite a long time
without understanding its implementation ver well.
(The first time I used module loading was to re-order the scsi host scanning
about three or four years ago.
Using module was one of the few wasy aside from
physically swaping bus slots to change the scaned order of host adaptors back then.
The original kernel/distribution that I used then was
the one that came Yggrdrasil 1994, but I had upgraded
various pieces to use more modern kernel and tools.
I switched to Debian about two or three years ago.
Now I figure I must have have bumped into this module
configuration issues back when I switched to Debian,
but I must have taken care of them quickly
and forgotten about them completely if so.)
So anyway, this finally has answered my question that originated from
my observation about device name registration
under devfsd, module loading caused by devfsd, and
the module configuration mechanism under Debian GNU/Linux.
Below is attached in the hope that the quirks of debian module handling (or
good feature) will be more widely known amongkernel hackers so that
it would be easier to diagnose some questions from the
clueless Debian distribution users regarding modules.
Usually, the Debian's excellent package system
takes care of these details (for me at least), and
I have not encountered much difficulty before.
But this time, I am experimenting with
the kernel 2.4.x and devfs/devfsd before
the stable Debian distribution incorporates them.
Thanks to all people for the helpful tips.
Happy Hacking
Chiaki Ishikawa
Usage of /etc/modules in Debian GNU/Linux:
Debian's modutils script reads /etc/modules
file to load modules at boot time.
But the generic documentation about module use
distributed in /usr/src/linux/Documentation doesn't mention
this Debian-specific file at all.
Grepping the files with /etc/modules and excluding /etc/modules.conf
resulted in only three hits and they refer to different entity (/etc/modules
being a directory where the modules are stored, it seems.)
This gets me confused, and I needed to read the various documents to see if what I gather
from reading S20modutils is correct.
man modules
produced a very short explanation of /etc/modules.
Quote: "The /etc/modules file contains the names of
kernel modules that are to be loaded at boot time, one
per line."
To summarize, the special entry
"auto" forces the use of kerneld at boot time.
Without it, it seems that when the initlevel
changes to 2, 3, 4 or 5, the kerneld is invoked.
I need to see if this is indeed Debian specific.
If so, this might explain why no one mentions the apparent
/etc/modules (instead of /etc/modules.conf, etc.)
when I raised my question about "sg" being loaded seemingly
without my calling for it.
Before writing this memo, I tried to see if other
distributions use similar mechanisms ("What is this
/etc/modules?" was my first reaction after looking
the modutils init script.) and after
reading the following pages found doing web search,
I am fairly convinced that this /etc/modules file is Debian-only concoction.
Debian distribution is trying to be clever using
/etc/modules and it seems to work most of the time, but
sometimes this could lead to user confusion.
(It is like offering nice GUI for configuration management without
the user/operator realizing what gos underneath.
Please don't think I am disparaging Debian. It is excellent distribution
and that is why I use it now.)
/etc/modules.conf is also not to be manually edited under Degian GNU/Linux.
Instead module developers are encouraged to create
entry files under the directory /etc/modutils
to be combined and inseted into the final /etc/modules.conf.
Running modconf(?) seems to integrate all the entry files into
the final /etc/modules.conf...
My system has these entries below /etc/modutils now.
duron:/home/ishikawa# ls -l /etc/modutils
total 32
-rw-r--r-- 1 root root 432 Nov 23 02:05 0keep
-rw-r--r-- 1 root root 1146 Nov 13 22:37 aliases
drwxr-xr-x 2 root root 4096 Dec 1 03:53 arch
-rw-r--r-- 1 root root 2753 Sep 12 05:41 devfsd
-rw-r--r-- 1 root root 260 Dec 25 1999 paths
-rw-r--r-- 1 root root 37 Dec 24 1998 pcmcia
-rw-r--r-- 1 root root 117 Jan 21 2000 raidtools
-rw-r--r-- 1 root root 494 May 9 2000 setserial
Yes, most of the time, Debian's great packaging system
takes care these details automatically, so we don't need
to dive into these details.
This time, I was experimenting with devfs/devfsd before
the stable release of Debian incorporates devfs yet.
Being a curious type, I could not help wondering
why "sg" was loaded automagically, and found out
that I didn't know much about Debian's own module config
mechanism at all!
cf. pages I found after google search Debian /etc/modules
Some exchanges concerning this on debian-user mailing list:
http://www.geocrawler.com/archives/3/199/2000/7/50/4119224/
http://www.geocrawler.com/archives/3/199/2000/7/50/4119745/
A page about module usage (generic explanation, but it has a
caveat abut Debain near the end.)
http://www.users.dircon.co.uk/~trix/Raven/EyeView/SSR02/SSR02-10.htm
One posting to lpi-discuss mailing list (I think this is where
the discussion on the proposed Linux professional certificate
of a sort is done. A paragraph mentions the inter-distribution
differences of various config files related to modules.
Wish I had known
about the differences in advance.)
http://www.lpi.org/archives/lpi-discuss/2000-02/msg00003.html
One user of filesystem coda was also confused initially
but figured it out about how Debian module config system worked.
http://www.coda.cs.cmu.edu/maillists/codalist-2000/0337.html
One post to a mailing list where the debian way of module
loading, /etc/modules, is mentioend very briefly. Long URL.
http://faqchest.dynhost.com/linux/KPLUG/kplug-00/kplug-0010/kplug-001014/kplug00101608_14774.html
PS: my original comment about the
devfs readme file under /usr/src/linux/Documentation/fs/devfs is still valid.
The device names are not quite up to date and match the currently used ones.
I wonder if someone in the know can upgrade at least the device names in the file.
[end of mail.]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/