Re: devfs: "cd" device not showing up initially. [Fwd: Scan past lun 7 in

Re: devfs: "cd" device not showing up initially. [Fwd: Scan past lun 7 in

[Douglas Gilbert]

 	
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ishikawa <ishikawa@yk.rim.or.jp> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: devfs: "cd" device not showing up initially. [Fwd: Scan past lun 7 in

[Ishikawa]

[-- Attachment #1: Type: text/plain, Size: 2989 bytes --]

>
>
> > 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,

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 )?
Otherwise I can't explain why "generic" was already
present when I ran "ls", but "cd" wasn't.
(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?)
Maybe I am missing something here regarding module
loading very much.

Also, my setting may be quite Debian GNU/Linux
specific.

Anyway, I looked again very carefully at the devfs README file
under

    /usr/src/linux/Documenation/filesystems/devfs

and found it a litte out of date.

 -   Richard Booch has a document
     dated Oct 16, 2000 at the URL site mentioned in the
     README file.

     The one under /usr/src/linux/Documentation/filesystems/devfs
     is dated 3-JUL-2000.

     So at least, we might want to upgrade the document
     to the latest available from the original author.

 -   Yet, even the one at the URL site doesn't
     reflect the name changes that took place last year.
     SCSI device names and others are not quite up to date and
     don't agree with what we see on the real system.
     (I am assuming that this is generally true and
      not Debian-specific.)

Attached is my first cut to update the of the document.
I would appreciate it if the README document is updated
to reflect the current implemntation.
I would be glad to help by typing the first rough draft
initially according to the suggestions.

Happy Hacking,

Chiaki Ishikawa



[-- Attachment #2: README.devfs.diff --]
[-- Type: text/plain, Size: 2898 bytes --]

*** /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

Re: devfs: "cd" device not showing up initially. [Fwd: Scan past lun 7 in

[Douglas Gilbert]

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'.

-
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://vger.kernel.org/lkml/

Found out why "sg" was loaded automagically. Re: devfs: "cd" device not showing up initially.

[Ishikawa]

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.]