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/