From: Douglas Gilbert <dougg@torque.net>
To: linux-kernel@vger.kernel.org
Cc: linux-scsi@vger.kernel.org, ishikawa@yk.rim.or.jp
Subject: Re: devfs: "cd" device not showing up initially. [Fwd: Scan past lun 7 in
Date: Sat, 10 Feb 2001 14:26:20 -0500 [thread overview]
Message-ID: <3A8595DC.B33CB0B2@torque.net> (raw)
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/
next reply other threads:[~2001-02-10 19:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-10 19:26 Douglas Gilbert [this message]
2001-02-12 2:35 ` devfs: "cd" device not showing up initially. [Fwd: Scan past lun 7 in Ishikawa
2001-02-12 17:22 ` Douglas Gilbert
2001-03-02 19:28 ` Found out why "sg" was loaded automagically. Re: devfs: "cd" device not showing up initially Ishikawa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A8595DC.B33CB0B2@torque.net \
--to=dougg@torque.net \
--cc=ishikawa@yk.rim.or.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.