Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ishikawa <[email protected]> wrote:
>
> I have begun using devfs for about a couple of weeks now and
> thank you for the great addition to linux.
> Now I am happy to see the device names on the
> scsi chain which won't be changed just because
> I add/delete a device.
>
> However, I noticed that there seems to be a subtle interaction of
> devfs (+devfsd) and
> the device names that appear under luns for
> a scsi chain.
>
> Namely the name "generic" or "disc" seem to
> exist from the start (after bootup), but
> the entry "cd" doesn't exist until I do something
> about accessing the CD somehow.
> (It seems that I fail the initial
> attempt to mount due to the missing name.)
>
> [snip, ls on /dev/scsi/* looks correct]
>
> Is it possible that the accessing the CD using the
> compatibility device name /dev/sr* forced
> the creation of the "cd" device name?
Yes, the LOOKUP rule caused 'modprobe sr_mod' to be
executed, then your cd devices will be visible in
devfs and accessible. Under the old /dev system
they were always "visible" but not accessible until
you loaded sr_mod .
> I consider the possibility of module loading. Both SCSI CD and
> SCSI generic (sg) are modules now.
> I checked /etc/devfs/devfs.conf (experimental Debian package
> puts the config file here! ) has the following line:
>
> LOOKUP .* MODLOAD
>
> So the module autoloading ought to work. ("generic" exists
> somehow from the start.)
Chiaki,
The upper level scsi drivers (sd, sr, st, osst and sg) register
and unregister device names with devfs. After the mid level
recognizes a new scsi device it calls the detect() function
in the builtin upper level drivers and those that are currently
loaded as modules. That is your "problem", sr_mod.o is not
loaded until you do something like "ls -l /dev/sr0" (due to
that LOOKUP rule in /etc/devfsd.conf). The lsmod command will
show which modules are loaded (in your case look for sr_mod).
There is no "push" mechanism in the scsi mid level to load
the sr_mod.o module when it sees a device with SCSI type
CDROM. Devfs (specifically devfsd) supplies various "pull"
mechanisms (e.g. LOOKUP) to load that module.
Doug Gilbert
*** /usr/src/linux/Documentation/filesystems/devfs/README Thu Nov 30 03:11:38 2000
--- README.devfs Mon Feb 12 11:15:29 2001
***************
*** 444,447 ****
--- 444,460 ----
openings.
+ [In the current implementation as of Feb 2001,
+ all the existing CD-ROM drives
+ appear under /dev/cdroms as cdrom0, cdrom1, ..., etc.
+ with appropriate symlinks pointing to the real CD device as in the following
+ snippet.
+
+ lr-xr-xr-x 1 root root 34 Jan 1 1970 cdrom0 -> ../scsi/host1/bus0/target5/lun1/cd
+ lr-xr-xr-x 1 root root 34 Jan 1 1970 cdrom1 -> ../scsi/host1/bus0/target6/lun0/cd
+ lr-xr-xr-x 1 root root 34 Jan 1 1970 cdrom2 -> ../scsi/host1/bus0/target6/lun1/cd
+
+ There is no /dev/sr. ]
+
+
-----------------------------------------------------------------------------
***************
*** 1035,1039 ****
cd
-
The SCSI generic driver creates:
--- 1048,1051 ----
***************
*** 1132,1135 ****
--- 1144,1161 ----
+ [The current implemenation as of Feb 2001 uses the following scheme?
+
+ All the discs including IDE are put under
+ /dev/discs/
+ disc0, disc1, disc2, ...
+
+ All the entries are symlinks to the real device names under /dev/ide,
+ /dev/scsi, etc..
+ eg.
+ disc0 -> ../ide/host0/bus0/target0/lun0
+ disc1 -> ../scsi/host0/bus0/target4/lun0
+ disc2 -> ../scsi/host1/bus0/target5/lun0
+ ]
+
SCSI Tapes
***************
*** 1148,1151 ****
--- 1174,1181 ----
+ [The current implemenation as of Feb 2001 uses the following scheme?
+ Insert the current usage . ]
+
+
SCSI CD-ROMs
***************
*** 1156,1161 ****
--- 1186,1226 ----
/dev/sr/c1b2t3u4
+ [The above should be completely rewritten. ]
+ The current implemenation as of Feb 2001 uses the following scheme?
+
+ All the CD-ROMs including the SCSI CD-ROMs are put under
+ /dev/cdrom
+
+ cdrom0 -> ../scsi/host1/bus0/target5/lun1/cd
+ cdrom1 -> ../scsi/host1/bus0/target6/lun0/cd
+ cdrom2 -> ../scsi/host1/bus0/target6/lun1/cd
+
+ There is no /dev/sr. ]
+
+
SCSI Generic Devices
+
+ [CI's comment: There is something wrong with the following
+ paragraph. There is no /dev/sg to begin with.
+ Shouldn't the original sentence ought to read
+ "All SCSI generic devices are placed ..."?
+ We can probably simply state that
+ SCSI generic devices appear under the
+ device directory of the form
+ /dev/scsi/hostC/busB/targetT/lunU/
+
+
+ Eg. C=1, B=0, T=6, U=2
+
+ /dev/scsi/host1/bus0/target6/lun2:
+ sum 0
+ drwxr-xr-x 1 root root 0 Jan 1 1970 .
+ drwxr-xr-x 1 root root 0 Jan 1 1970 ..
+ brw-rw---- 1 root cdrom 11, 3 Jan 1 1970 cd
+ crw------- 1 root root 21, 5 Jan 1 1970 generic
+
+ ]
+
All SCSI CD-ROMs are placed under /dev/sg. A similar naming
Ishikawa wrote:
>
> > Chiaki,
> > The upper level scsi drivers (sd, sr, st, osst and sg) register
> > and unregister device names with devfs. After the mid level
> > recognizes a new scsi device it calls the detect() function
> > in the builtin upper level drivers and those that are currently
> > loaded as modules. That is your "problem", sr_mod.o is not
> > loaded until you do something like "ls -l /dev/sr0" (due to
> > that LOOKUP rule in /etc/devfsd.conf). The lsmod command will
> > show which modules are loaded (in your case look for sr_mod).
> >
> > There is no "push" mechanism in the scsi mid level to load
> > the sr_mod.o module when it sees a device with SCSI type
> > CDROM. Devfs (specifically devfsd) supplies various "pull"
> > mechanisms (e.g. LOOKUP) to load that module.
>
> Doug,
>
> Thank you for enlightening me on the subtle
> interaction of module loading and devfs.
>
> One thing that confused me was that "generic" was
> present On my system, I use the module version of
> scsi generic driver.
> Am I right then assuming that SCSI subsystem
> somehow supports the loading of "sg" driver module
> automagically (as opposed to mod_sr.o )?
Chiaki,
No, there is no special code in the kernel SCSI
subsystem to load the sg driver.
The only special ("push") code within the SCSI subsystem
is a mid-level attempt to load a module called
"scsi_hostadapter". This will happen when any upper level
driver is registered _and_ there is not already a lower
level driver (i.e. adapter driver) registered.
[Hotplugging devices (e.g. USB mass storage) may be a
good reason to add some more "push" code.]
> Otherwise I can't explain why "generic" was already
> present when I ran "ls", but "cd" wasn't.
It only requires one lookup on a /dev/sg* device name
to trigger devfsd (1.3.11) to load sg. Perhaps you need
to closely examine devfsd's configuration files:
- /etc/devfsd.conf
- /etc/modules.devfs [you are not meant to change this one]
- /etc/modules.conf
There could also be something hidden away in your "rc"
system initialization scripts.
> (During the boot I see the string "sg" just prior to the
> loading of tmscsim (DC390) driver module. The NCR driver
> is built-in and recognized earlier. Aha, could it be that
> "sg" is used for the initial probing of
> device types and such?)
No, unless you call an app like SANE, cdrecord or scsidev.
I am aware that Debian are looking at devfs. Doing
'modprobe sg' is one way of populating the /dev/scsi
subtree when using devfs.
Doug Gilbert
P.S. Perhaps you could send me a copy of the 3 configuration
files mentioned above and the output from 'dmesg'.
Some time ago, I posted a question concerning
the device name "cd" (module sr_mod) not appearing automatically
under my 2.4.x devfs/devfsd configuration.
However, "generic" (module sg) does appear
automagically. This confused me a bit.
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.]