Jean-David Beyer <jdbeyer@exit109.com> writes:

>Jean-David Beyer wrote:
>> imotgm wrote:
>>
>>>On Sat, 03 Dec 2005 08:40:36 -0500, Jean-David Beyer wrote:
>>>
>>>
>>>
>>>>imotgm wrote:
>>>>
>>>>
>>>>>On Fri, 02 Dec 2005 09:56:39 -0500, Jean-David Beyer wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>OK all seems to work other than finding where to put the modprobe command.
>>>>>
>>>>>
>>>>>Do you have a file /etc/modprobe.preload?
>>>>
>>>>No. Only /etc/modprobe.conf
>>>>
>>>>That is where I put
>>>>
>>>># Try to load sg for tape and PleXTor controllers.
>>>>install sg /bin/true
>>>
>>>
>>>Are you sure that "/bin/true" is a good idea?
>>
>>
>> No, I am not. I just copied an entry from
>> /sbin/modprobe -c
>> or some such place. I cannot check that right now as that machine is
>> currently running Windows XP.
>>
>> Wherever it was, it showed me all the stuff similar to /etc/modprobe.conf,
>> including everything from /etc/modprobe.conf, but much much more. There was
>> where I saw the entry that, IIRC went something like this:
>>
>> install something /bin/true
>>
>> and I just made the obvious change.
>>
>> Syntax of "install" is:
>>
>> install module command ...
>>
>> so I infer that /bin/true is as good a command as any, since I do not want
>> it to fail.
>>
>> But if that does not work, I suppose /bin/false would do it.
>>
>>>From man true;
>>>
>>>TRUE(1) User Commands TRUE(1)
>>>
>>>NAME
>>> true - do nothing, successfully
>>>
>>>This is the command that SUSE specifies to STOP using ipv6
>>>
>>>install ipv6 /bin/true
>>>
>>>and it does.
>>>
>>>
>>>
>>>>But I have not rebooted since, so I do not know if it works or not, but I
>>>>imagine it will.
>>>
>>>
>>>If it doesn't, try losing the "/bin/true". I think that will screw you up.
>>>
>>
>> According to the syntax, I must have a command argument, so if true makes it
>> fail, then false should make it work.
>>
>Well, nothing I put into /etc/modprobe.conf will work. No error messages or
>anything, but the module does not load. I infer that modprobe.conf is there
>to help the modprobe command work, but no one is invoking it.

>I gave up and stuck

>/sbin/modprobe sg

>into /etc/rc.d/rc.sysinit

>just after where it says

>/sbin/modprobe floppy

/etc/modules is often where modules that you want brought up on bootup are
put.
/etc/modprobe.conf is for aliases. Eg, eth0 is really one of 47 different
etehrnet cards, but you just want to refer to that one name despite which
card you have.
Putting "sg /bin/true" into modprobe.conf would say that if the system asks for
the module sg the system should really try to load the module /bin/true,
which is not a module and will fail.

modprobe.conf certain IS referenced by the system. Just try doing say
modprobe -e eth0 assuming you have an eth0 line in /etc/modprobe.conf
You will suddenly find yourself without ethernet access.
Even though there is no module called eth0.o.kz

Enrique Perez-Terron wrote:
> On Sun, 04 Dec 2005 09:38:44 +0100, Jean-David Beyer
> <jdbeyer@exit109.com> wrote:
>
>> Jean-David Beyer wrote:
>
>
>> I gave up and stuck
>>
>> /sbin/modprobe sg
>>
>> into /etc/rc.d/rc.sysinit
>>
>> just after where it says
>>
>> /sbin/modprobe floppy
>>
>> Of course that works, but I am convinced there must be a better way.
>
>
> Depending on how much time you want to spend on this, you may be able to
> figure out where the modprobe command should have been, considering the
> following, for some meaning of "should have been". However, be warned
> that the following is 70% guessing on my part, and I post it much in
> the hope of eliciting corrections from people who know more.
>
> As to the "should have been", I guess an admissible definition would
> consider if it fits into the framework that the maintainers of the
> rc.sysinit file are trying to implement; that lets the software issue
> the right modprobe commands on all relevant installations of the
> distribution; that is, something that could be contributed to the
> maintainer. If maintainers accept it, you don't have to worry about
> it the next time you upgrade the initscripts package.

I do not see why the system maintainers should accept it. I might as well
build the sg module into the kernel. And some people do not want or need it,
so why should they be stuck with it. I am convinced it does not belong in
/etc/rc.d/rc/sysinit. Of course,
/sbin/modprobe floppy
is in there too, and I do not think it belongs.
>
> The disadvantage of just sticking the modprobe command in rc.sysinit
> is that you will have to remember to repeat the modifation each time
> the initscripts package is upgraded. Sticking it in rc.local, you don't
> face that problem. That is what rc.local is for.

Well, yes.
>
> My understanding of the current udev architecture is that, as the kernel
> enumerates buses and devices, it creates nodes in /sys/devices/* exporting
> attributes of the devices, and it invokes the program named in
> /proc/sys/kernel/hotplug with some data about the device placed in the
> program's environment.

I do not know who creates the stuff in /sys/devices, but my sg3 is in there
somewhere. I found it.

$ cat /proc/sys/kernel/hotplug
/sbin/hotplug
>
> For devices being hotplugged after the system has booted, the set of
> programs
> and scripts invoked from the hotplug program, embodies the knowledge about
> what modules should be loaded. Once a module is loaded, its
> initialization may
> produce further hotplug events.

Now the system at some point comes up with
/dev/scd0 which is the read-only aspect of the CD-ROM burner.
But it does not come up with
/dev/sg3 which is the write aspect of the CD-ROM burner.

But that SCSI controller is always on; i.e., it is an internal SCSI Host
Adapter card plugged into a PCI bus slot.

Now with RHL 7.3 and RHL 9, the kernel did not notice the SCSI burner unless
it was powered on during kernel boot. I assume this is still true, so I
always leave the unit powered on, even though I do not use it much.
Otherwise, if power fails and the UPS initiates a controlled shutdown, and
power comes back and the system reboots, no CD-ROM burner. Now I do not know
if powering on the CD-ROM burner amounts to hot plugging in the sense that
the kernel will look and see if I just did that. I am assuming it does not.
>
> For devices discovered before userland is available, and specifically
> before
> rc.sysinit writes a program path into /proc/sys/kernel/hotplug,

??? The string "/proc/sys/kernel/hotplug" does not exist in my rc.sysinit
file. It also does not appear in any file in /etc/sysconfig. or
/etc/rc.d/init.d.

> this system
> does not work without some extra help. I don't have any details about the
> rc.sysinit of your (CentOS) system, and I hardly understand half of what my
> (Fedora Core 4) rc.sysinit does, but it seems to me that at some point the
> scripts and programs invoked from rc.sysinit do simulate hotplug events for
> devices found in /sys/devices at that time, by calling scripts in the
> hotplug/udev system with appropriate environment variables, presumably
> taking
> the info from the files in the sys/devices nodes.
>
> **update: I just read man udevstart. That seems to confirm my understanding
> pretty well.**
>
> From what you have written so far, I am under the impression that the
> current initscripts do discover the device, and do create /dev entries,
> but not of the right kind, and do not load the sg module. Once the module
> is loaded, the system does correctly create the /dev/sg* nodes.

The entries do discover the CDROM aspects of the device and create the
/dev/scd0
entry. But they do not discover the CD-R[W} aspects of the device and do not
create
/dev/sg3

They do not create any /dev/sg entries, not for my two SCSI hard drives, my
SCSI tape drive, nor my CD-R[W] drive. So whatever is the matter, it is more
serious than just the CD-R[W] drive.

In fact, it seems to me that if any SCSI module is loaded, which seems the
purpose of scsi.agent, it should always load the sg driver as well. But
should I modify the scsi-agent file to do this? That seems to be a bad idea.
Should not the loading of any scsi module cascade the loading of the sg
module as well?
>
> This makes me believe that the script you posted, scsi.agent is being run
> with the relevant device, but this script fails to embody the correct
> knowledge of what modules should be loaded. You mentioned the possibility
> of adding a branch to the "case" statement "case $TYPE" of...esac",
> if only you knew what the value of TYPE is for your device. The script
> loads this variable with the contents of a file /sys$DEVPATH/type.

Well, I looked in /usr/include/scsi/scsi.h and that shows, in part,

/*
* DEVICE TYPES
*/

#define TYPE_DISK 0x00
#define TYPE_TAPE 0x01
#define TYPE_PROCESSOR 0x03 /* HP scanners use this */
#define TYPE_WORM 0x04 /* Treated as ROM by our system */
#define TYPE_ROM 0x05
#define TYPE_SCANNER 0x06
#define TYPE_MOD 0x07 /* Magneto-optical disk -
* - treated as TYPE_DISK */
#define TYPE_MEDIUM_CHANGER 0x08
#define TYPE_ENCLOSURE 0x0d /* Enclosure Services Device */
#define TYPE_NO_LUN 0x7f

which sorta-kinda matches this part of scsi.agent:

TYPE=$(cat $TYPE_ATTR)
case "$TYPE" in
# 2.5.51 style attributes; <scsi/scsi.h> TYPE_* constants
0) TYPE=disk ; MODULE=sd_mod ;;
# FIXME some tapes use 'osst' not 'st'
1) TYPE=tape ; MODULE=st ;;
2) TYPE=printer ; MODULE=sg ;;
3) TYPE=processor ; MODULE=sg ;;
4) TYPE=worm ; MODULE=sr_mod ;;
5) TYPE=cdrom ; MODULE=sr_mod ;;
6) TYPE=scanner ; MODULE=sg ;;
7) TYPE=mod ; MODULE=sd_mod ;;
8) TYPE=changer ; MODULE=sg ;;
9) TYPE=comm ; MODULE=sg ;;
14) TYPE=enclosure ; MODULE=sg ;;
esac
if [ "$MODULE" != "" ]; then
mesg "$TYPE at $DEVPATH"
modprobe $MODULE
else
debug_mesg "how to add device type=$TYPE at $DEVPATH ??"
fi
;;

but if that is anything to go by, this won'd do either as there is no entry
for "CDRW" or whatever it might be called.

> I suggested you could look and see if you could find this file, first
> determining which directory in the /sys/devices tree corresponds to
> your dvd burner,

That would be this:

../0000:00:12.0/host1/target1:0:4/1:0:4:0:
total 0
lrwxrwxrwx 1 root root 0 Dec 4 15:30 block ->
../../../../../../block/sr0
--w------- 1 root root 4096 Dec 4 15:30 delete
-rw-r--r-- 1 root root 4096 Dec 4 15:30 detach_state
-r--r--r-- 1 root root 4096 Dec 4 15:30 device_blocked
-rw-r--r-- 1 root root 4096 Dec 4 15:30 dump
lrwxrwxrwx 1 root root 0 Dec 4 15:30 generic ->
../../../../../../class/scsi_generic/sg3
-r--r--r-- 1 root root 4096 Dec 4 15:30 model
drwxr-xr-x 2 root root 0 Dec 3 13:06 power
-r--r--r-- 1 root root 4096 Dec 4 15:30 queue_depth
--w------- 1 root root 4096 Dec 4 15:30 rescan
-r--r--r-- 1 root root 4096 Dec 4 15:30 rev
-r--r--r-- 1 root root 4096 Dec 4 15:30 scsi_level
-rw-r--r-- 1 root root 4096 Dec 4 15:30 state
-rw-r--r-- 1 root root 4096 Dec 4 15:30 timeout
-r--r--r-- 1 root root 4096 Dec 4 15:30 type
-r--r--r-- 1 root root 4096 Dec 4 15:30 vendor

> and then cat'ing the file "type" from this directory.

[/sys/devices/pci0000:00/0000:00:12.0/host1/target1:0:4/1:0:4:0]$ cat type
5

Well, "5" is true, as far as it goes, but it should also be something else
to get me both the

5) TYPE=cdrom ; MODULE=sr_mod ;;

and someting else to get me something like this:

126) TYPE=cdrw ; MODULE=sg ;;

in there.

> You seemed to find a directory node that could be the right one,
> but I don't know what more you did to pursue that. You focused a symlink
> to /dev/sg3, probably as a reason to believe this was the right node.
> You could also look at the contents of other files in the node, e.g.
> "model", to see if you find further evidence that this is indeed the
> right node.

[/sys/devices/pci0000:00/0000:00:12.0/host1/target1:0:4/1:0:4:0]$ cat model
CD-R PX-W1210S

This seems correct as it is one way my device identifies itself.

[/sys/devices/pci0000:00/0000:00:12.0/host1/target1:0:4/1:0:4:0]$ cat vendor
PLEXTOR

This is the correct vendor, and I have nothing else from PLEXTOR on my machine.
>
> I still don't know for sure if scsi.agent is being run with environment
> variables pointing to the cd burner.

It seems to me that it is, since it creates the /dev/scd0 node which is
required when an existing CD-ROM is in there and I want to mount it.

> If not, the cause of this needs
> being investigated. How do the initscripts proceed to decide to run
> scsi.agent, if at all? I suggest a few logging statements are added
> to both rc.sysinit and to scsi.agent. (NB! when rc.sysinit starts, the
> root file system is mounted readonly, and /var and /tmp, if on separate
> file systems, are not yet mounted. The only writable file system you
> probably can count on is /dev. This ramfs is mounted during initrd
> processing on my FC4 system.)
>
> Assuming the scsi.agent *is* being run, it would be interesting to
> know what the contents of the "type" file is. Or, even if it is not
> being run.
>
> BTW, there is a file /etc/hotplug/scsi.agent on my system too, and looks
> quite identical to what you posted. However, I cannot find any reference
> to it, with
>
> grep -r scsi.agent /etc/*hot* /etc/*dev* /etc/rc.d /sbin
>
> I have not yet tried to look for eg. $BUS.agent...
>
> **update: /etc/hotplug.d/default/default.hotplug seems to be the place:
>
> hotplug.d/default/default.hotplug: for AGENT in
> /etc/hotplug/*.agent ; do
> hotplug.d/default/default.hotplug: TYPE=`basename $AGENT | sed
> s/.agent//`
> hotplug.d/default/default.hotplug:# /sbin/hotplug FOO ..args.. ==>
> /etc/hotplug/FOO.agent ..args..
> hotplug.d/default/default.hotplug:AGENT=/etc/hotplug/$1.agent
>
>
> -Enrique


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 14:50:00 up 8 days, 1:20, 4 users, load average: 4.19, 4.24, 4.17

Unruh wrote:

>> I gave up and stuck
>
>> /sbin/modprobe sg
>
>> into /etc/rc.d/rc.sysinit
>
>> just after where it says
>
>> /sbin/modprobe floppy
>
> /etc/modules is often where modules that you want brought up on bootup
> are put.

$ ls -l /etc/modules
ls: /etc/modules: No such file or directory

Are you suggesting I create one?

> /etc/modprobe.conf is for aliases. Eg, eth0 is really one of 47
> different etehrnet cards, but you just want to refer to that one name
> despite which card you have.

Sort of; mine looks like this:

[/etc]$ cat modprobe.conf
alias eth0 e100
alias scsi_hostadapter sym53c8xx
alias usb-controller uhci-hcd

> Putting "sg /bin/true" into modprobe.conf
> would say that if the system asks for the module sg the system should
> really try to load the module /bin/true, which is not a module and will
> fail.
>
> modprobe.conf certain IS referenced by the system. Just try doing say
> modprobe -e eth0 assuming you have an eth0 line in /etc/modprobe.conf You
> will suddenly find yourself without ethernet access. Even though there is
> no module called eth0.o.kz
>
[/lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi]$ ls -l
total 1364
[snip]
-rwxr--r-- 1 root root 45976 Oct 27 15:08 sg.ko
-rwxr--r-- 1 root root 24656 Oct 27 15:08 sr_mod.ko
-rwxr--r-- 1 root root 46524 Oct 27 15:08 st.ko
[snip]
[/lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/net]$ ls -l
total 1636
-rwxr--r-- 1 root root 52160 Oct 27 15:08 3c59x.ko
[snip]
-rwxr--r-- 1 root root 46108 Oct 27 15:08 e100.ko
drwxr-xr-x 2 root root 4096 Oct 29 11:32 e1000
[snip]

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 15:50:00 up 8 days, 2:20, 4 users, load average: 4.16, 4.15, 4.15

On Sun, 04 Dec 2005 21:48:48 +0100, Jean-David Beyer <jdbeyer@exit109.com> wrote:

> Enrique Perez-Terron wrote:

>> As to the "should have been", I guess an admissible definition would
>> consider if it fits into the framework that the maintainers of the
>> rc.sysinit file are trying to implement; that lets the software issue
>> the right modprobe commands on all relevant installations of the
>> distribution; that is, something that could be contributed to the
>> maintainer. If maintainers accept it, you don't have to worry about
>> it the next time you upgrade the initscripts package.
>
> I do not see why the system maintainers should accept it. I might as well
> build the sg module into the kernel. And some people do not want or need it,
> so why should they be stuck with it. I am convinced it does not belong in
> /etc/rc.d/rc/sysinit. Of course,
> /sbin/modprobe floppy
> is in there too, and I do not think it belongs.

The idea is this: The distro is readied by some guys and distributed,
then it lands on a few tens of thousands of different computers. The
distro cannot embody knowledge like "this computer has a PleXTor cd
burner connected to a scsi controller", but it can embody "if the
running computer does have so-and-so, load module sg - unless it is
compiled in."

This is what makes the distro "run out of the box" for most users.

In the bad old days, all device discovery happened at boot time; devices
did not come and go in the middle of the uptime. All logic to decide
what modules to load did hang off rc.sysinit. It did not have to reside
entirely in rc.sysinit, but could be in programs run by rc.sysinit.

With the advent of USB particularly, devices began appearing and
disappearing as never before. (I know, pcmcia and cardbus has been
around a while, but I believe USB is what finally sparked the current
evolution in the device handling. Wireless technologies like Bluetooth
also accentuated the need.)

So the hotplug system was invented, and much of the device-module logic
moved into it. That move of course left many Unix/Linux oldtimers like
myself mystified: Why do these /dev files pop up out of nowhere? And
when the /dev files for some reason don't materialize, where on earth do
I look to correct it? So also with the modules. To this day I have
not seen a good description of how this works, other than small pieces
written in a language from Jupiter, describing the relations between the
sixth and seventh cogwheel.

>> My understanding of the current udev architecture is that, as the kernel
>> enumerates buses and devices, it creates nodes in /sys/devices/* exporting
>> attributes of the devices, and it invokes the program named in
>> /proc/sys/kernel/hotplug with some data about the device placed in the
>> program's environment.
>
> I do not know who creates the stuff in /sys/devices, but my sg3 is in there
> somewhere. I found it.

The kernel does!!

The /sys directory is empty, actually, (or any contents get hidden by
the mount), but rc.sysinit mounts a "sysfs" filesystem there. That
is a virtual file system, nothing is written to disk, just like /proc
and procfs. There is no "device" mounted, the "device" argument to
the mount command is any dummy word.

In the scsi.agent script you see "/sys$DEVPATH", because the decision
to mount the sysfs on just "/sys" is a userland decision, the kernel
does not know that in advance. But the value of DEVPATH is entirely
determined by the kernel, and exported to userland in the environment
of the program named in /proc/sys/kernel/hotplug. The sysfs is there
precisely to give the userland something to go on when figuring out
what modules to load and what device node files to create.

This is why I suggest you explore the contents of the files in the
directory node you found, to see what does the kernel reveal about the
device, upon which a decision could be based.

> $ cat /proc/sys/kernel/hotplug
> /sbin/hotplug
>>
>> For devices being hotplugged after the system has booted, the set of
>> programs
>> and scripts invoked from the hotplug program, embodies the knowledge about
>> what modules should be loaded. Once a module is loaded, its
>> initialization may
>> produce further hotplug events.
>
> Now the system at some point comes up with
> /dev/scd0 which is the read-only aspect of the CD-ROM burner.
> But it does not come up with
> /dev/sg3 which is the write aspect of the CD-ROM burner.

There is a file in the Documentation directory of the kernel source, about
the sg driver:

The SCSI Generic driver (sg) is one of the four "high level" SCSI device
drivers along with sd, st and sr (disk, tape and CDROM respectively). Sg
is more generalized (but lower level) than its siblings and tends to be
used on SCSI devices that don't fit into the already serviced categories.
Thus sg is used for scanners, CD writers and reading audio CDs digitally
amongst other things.

From this, I wonder if there is any generic way to determine from what
the kernel sees on the bus, and exports in /sys/devices, if the sg driver
is required. In the world of USB devices, there is a notion of "class",
allowing device producers to mark their devices in a way that allows
the kernel to figure out what to do. I just don't know that much about
scsi, if there is any equivalent.

It seems possible at this point that the only generic way is to put the
"modprobe sg" in rc.local, with or without a test for the contents of
the "model" file in the /sys/devices node (I don't know what it contains.
For what I know, it could be a string identifying the device, or it could
be a number, which has to be looked up in a directory. Or perhaps it does
not identify the device at all.)

**Update** I see you tell this below. Also see /proc/sys/dev/cdrom/info,
which I discovered below.**

But looking around some more, I find some rules in /etc/hotplug/rules.d/*
(line breaks with "\" are by me):

KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", \
PROGRAM=="/etc/udev/scripts/check-cdrom.sh %k CD-R", SYMLINK="cdwriter%e"
KERNEL=="sr[0-9]*", BUS=="scsi", \
PROGRAM=="/etc/udev/scripts/check-cdrom.sh %k CD-R", SYMLINK="cdwriter%e"

KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", \
PROGRAM="/etc/udev/scripts/check-cdrom.sh %k DVD-R", SYMLINK="dvdwriter%e"
KERNEL=="sr[0-9]*", BUS=="scsi", \
PROGRAM=="/etc/udev/scripts/check-cdrom.sh %k DVD-R", SYMLINK="dvdwriter%e"

# rename sr* to scd*
KERNEL=="sr[0-9]*", BUS=="scsi", NAME="scd%n"
KERNEL=="hd[a-z]*", BUS=="ide", SYSFS{removable}=="1", NAME{ignore_remove}="%k"

This seems to point to an ability to determine if a device is a cd writer,
in which case it seems that loading "sg" is appropriate, according to the
quote above.

Looking at /etc/udev/scripts/check-cdrom.sh, it turns out to read /proc/
sys/dev/cdrom/info. Another surprise. On my system, cat /proc/sys/dev/cdrom/info:

CD-ROM information, Id: cdrom.c 3.20 2003/12/17

drive name: hdd
drive speed: 32
drive # of slots: 1
Can close tray: 1
Can open tray: 1
Can lock tray: 1
Can change speed: 1
Can select disk: 0
Can read multisession: 1
Can read MCN: 1
Reports media changed: 1
Can play audio: 1
Can write CD-R: 1
Can write CD-RW: 1
Can read DVD: 0
Can write DVD-R: 0
Can write DVD-RAM: 0
Can read MRW: 1
Can write MRW: 1
Can write RAM: 1

Is there similar information on your system?

> But that SCSI controller is always on; i.e., it is an internal SCSI Host
> Adapter card plugged into a PCI bus slot.
>
> Now with RHL 7.3 and RHL 9, the kernel did not notice the SCSI burner unless
> it was powered on during kernel boot. I assume this is still true, so I
> always leave the unit powered on, even though I do not use it much.
> Otherwise, if power fails and the UPS initiates a controlled shutdown, and
> power comes back and the system reboots, no CD-ROM burner. Now I do not know
> if powering on the CD-ROM burner amounts to hot plugging in the sense that
> the kernel will look and see if I just did that. I am assuming it does not.

Hard to say except by trying. I guess scsi wasn't invented with hotplug
in mind, so there may not be anything there that invokes the kernel's hotplug
mechanisms.

>> For devices discovered before userland is available, and specifically
>> before
>> rc.sysinit writes a program path into /proc/sys/kernel/hotplug,
>
> ??? The string "/proc/sys/kernel/hotplug" does not exist in my rc.sysinit
> file. It also does not appear in any file in /etc/sysconfig. or
> /etc/rc.d/init.d.

Yes, ???.

On my system, rc.sysinit:

# Initialize hardware
if [ -f /proc/sys/kernel/modprobe ]; then
if ! strstr "$cmdline" nomodules && [ -f /proc/modules ] ; then
sysctl -w kernel.modprobe="/sbin/modprobe" >/dev/null 2>&1
sysctl -w kernel.hotplug="/sbin/udevsend" >/dev/null 2>&1
else
# We used to set this to NULL, but that causes 'failed to exec' messages"
sysctl -w kernel.modprobe="/bin/true" >/dev/null 2>&1
sysctl -w kernel.hotplug="/bin/true" >/dev/null 2>&1
fi
fi

If yours is similar, you'll have to leave out "/proc/sys/" from the regexp.

>> From what you have written so far, I am under the impression that the
>> current initscripts do discover the device, and do create /dev entries,
>> but not of the right kind, and do not load the sg module. Once the module
>> is loaded, the system does correctly create the /dev/sg* nodes.
>
> The entries do discover the CDROM aspects of the device and create the
> /dev/scd0
> entry. But they do not discover the CD-R[W} aspects of the device and do not
> create
> /dev/sg3
>
> They do not create any /dev/sg entries, not for my two SCSI hard drives, my
> SCSI tape drive, nor my CD-R[W] drive. So whatever is the matter, it is more
> serious than just the CD-R[W] drive.
>
> In fact, it seems to me that if any SCSI module is loaded, which seems the
> purpose of scsi.agent, it should always load the sg driver as well. But
> should I modify the scsi-agent file to do this? That seems to be a bad idea.
> Should not the loading of any scsi module cascade the loading of the sg
> module as well?

If /proc/sys/dev/cdrom does contain the necessary information, you could add
a test for it in scsi.agent. Or write to your distro's maintainers (bugzilla?)
and elicit some thoughts. I can't imagine they don't want to have cd burners
work "out of the box".

>>
>> This makes me believe that the script you posted, scsi.agent is being run
>> with the relevant device, but this script fails to embody the correct
>> knowledge of what modules should be loaded. You mentioned the possibility
>> of adding a branch to the "case" statement "case $TYPE" of...esac",
>> if only you knew what the value of TYPE is for your device. The script
>> loads this variable with the contents of a file /sys$DEVPATH/type.
>
> Well, I looked in /usr/include/scsi/scsi.h and that shows, in part,
>
> /*
> * DEVICE TYPES
> */
>
> #define TYPE_DISK 0x00
> #define TYPE_TAPE 0x01
> #define TYPE_PROCESSOR 0x03 /* HP scanners use this */
> #define TYPE_WORM 0x04 /* Treated as ROM by our system */
> #define TYPE_ROM 0x05
> #define TYPE_SCANNER 0x06
> #define TYPE_MOD 0x07 /* Magneto-optical disk -
> * - treated as TYPE_DISK */
> #define TYPE_MEDIUM_CHANGER 0x08
> #define TYPE_ENCLOSURE 0x0d /* Enclosure Services Device */
> #define TYPE_NO_LUN 0x7f
>
> which sorta-kinda matches this part of scsi.agent:
>
> TYPE=$(cat $TYPE_ATTR)
> case "$TYPE" in
> # 2.5.51 style attributes; <scsi/scsi.h> TYPE_* constants
> 0) TYPE=disk ; MODULE=sd_mod ;;
> # FIXME some tapes use 'osst' not 'st'
> 1) TYPE=tape ; MODULE=st ;;
> 2) TYPE=printer ; MODULE=sg ;;
> 3) TYPE=processor ; MODULE=sg ;;
> 4) TYPE=worm ; MODULE=sr_mod ;;
> 5) TYPE=cdrom ; MODULE=sr_mod ;;
> 6) TYPE=scanner ; MODULE=sg ;;
> 7) TYPE=mod ; MODULE=sd_mod ;;
> 8) TYPE=changer ; MODULE=sg ;;
> 9) TYPE=comm ; MODULE=sg ;;
> 14) TYPE=enclosure ; MODULE=sg ;;
> esac
> if [ "$MODULE" != "" ]; then
> mesg "$TYPE at $DEVPATH"
> modprobe $MODULE
> else
> debug_mesg "how to add device type=$TYPE at $DEVPATH ??"
> fi
> ;;
>
> but if that is anything to go by, this won'd do either as there is no entry
> for "CDRW" or whatever it might be called.

It seems that the "type" more or less covers the functionality of "class" in
USB, but that the classification is not adequate to decide if sg should be loaded
or not.



>> I suggested you could look and see if you could find this file, first
>> determining which directory in the /sys/devices tree corresponds to
>> your dvd burner,
>
> That would be this:
>
> ./0000:00:12.0/host1/target1:0:4/1:0:4:0:
> total 0
> lrwxrwxrwx 1 root root 0 Dec 4 15:30 block ->
> ../../../../../../block/sr0
> --w------- 1 root root 4096 Dec 4 15:30 delete
> -rw-r--r-- 1 root root 4096 Dec 4 15:30 detach_state
> -r--r--r-- 1 root root 4096 Dec 4 15:30 device_blocked
> -rw-r--r-- 1 root root 4096 Dec 4 15:30 dump
> lrwxrwxrwx 1 root root 0 Dec 4 15:30 generic ->
> ../../../../../../class/scsi_generic/sg3
> -r--r--r-- 1 root root 4096 Dec 4 15:30 model
> drwxr-xr-x 2 root root 0 Dec 3 13:06 power
> -r--r--r-- 1 root root 4096 Dec 4 15:30 queue_depth
> --w------- 1 root root 4096 Dec 4 15:30 rescan
> -r--r--r-- 1 root root 4096 Dec 4 15:30 rev
> -r--r--r-- 1 root root 4096 Dec 4 15:30 scsi_level
> -rw-r--r-- 1 root root 4096 Dec 4 15:30 state
> -rw-r--r-- 1 root root 4096 Dec 4 15:30 timeout
> -r--r--r-- 1 root root 4096 Dec 4 15:30 type
> -r--r--r-- 1 root root 4096 Dec 4 15:30 vendor
>
>> and then cat'ing the file "type" from this directory.
>
> [/sys/devices/pci0000:00/0000:00:12.0/host1/target1:0:4/1:0:4:0]$ cat type
> 5
>
> Well, "5" is true, as far as it goes, but it should also be something else
> to get me both the
>
> 5) TYPE=cdrom ; MODULE=sr_mod ;;
>
> and someting else to get me something like this:
>
> 126) TYPE=cdrw ; MODULE=sg ;;
>
> in there.

Agreed.


>> You seemed to find a directory node that could be the right one,
>> but I don't know what more you did to pursue that. You focused a symlink
>> to /dev/sg3, probably as a reason to believe this was the right node.
>> You could also look at the contents of other files in the node, e.g.
>> "model", to see if you find further evidence that this is indeed the
>> right node.
>
> [/sys/devices/pci0000:00/0000:00:12.0/host1/target1:0:4/1:0:4:0]$ cat model
> CD-R PX-W1210S
>
> This seems correct as it is one way my device identifies itself.
>
> [/sys/devices/pci0000:00/0000:00:12.0/host1/target1:0:4/1:0:4:0]$ cat vendor
> PLEXTOR
>
> This is the correct vendor, and I have nothing else from PLEXTOR on my machine.
>>
>> I still don't know for sure if scsi.agent is being run with environment
>> variables pointing to the cd burner.
>
> It seems to me that it is, since it creates the /dev/scd0 node which is
> required when an existing CD-ROM is in there and I want to mount it.

Having a couple of burns from earlier quick assumptions, I prefer to add

echo "$0" "$@" >> /dev/mylog
set >> /dev/mylog

to the scsi.agent file, and look for /dev/mylog after next reboot.

There seems to be code in /etc/rules.d/* to create the /dev/scd* nodes.

I have not investigated what execution paths lead to the
/etc/hotplug.d/default/default.hotplug which in turn seems to reference
scsi.agent.



I still wonder if there is a program like "kmodule" on your system, and what
exactly it does. In my rc.sysinit:

echo -n $"Initializing hardware... "

ide=""
scsi=""
network=""
audio=""
other=""
eval `kmodule -d | while read devtype mod ; do
case "$devtype" in
"IDE") ide="$ide $mod"
echo "ide=\"$ide"\";;
"SCSI") scsi="$scsi $mod"
echo "scsi=\"$scsi"\";;
"NETWORK") network="$network $mod"
echo "network=\"$network"\";;
"AUDIO") audio="$audio $mod"
echo "audio=\"$audio"\";;
*) other="$other $mod"
echo "other=\"$other"\";;
esac
done`

load_module () {
LC_ALL=C fgrep -xq "$1" /etc/hotplug/blacklist 2>/dev/null || modprobe $1 >/dev/null 2>&1
}

# IDE
for module in $ide ; do
load_module $module
done

# SCSI
for module in `/sbin/modprobe -c |
LC_ALL=C awk '/^alias[[:space:]]+scsi_hostadapter[0-9]*[[:space:]]/ { print $3 }'` $scsi; do
load_module $module
done
load_module floppy

echo -n $" storage"

kmodule belongs to the initscripts rpm package. I happen to have the
initscrips source rpm installed, but the functionality of kmodule turns
out to be in libkudzu. The documentation is wonderfull: zero doc files.

How does one determine if a driver is compiled-in? By the absence of
the module in /lib/modules/$(uname -r)/* ? Any better?

-Enrique

Enrique Perez-Terron wrote:
> On Sun, 04 Dec 2005 21:48:48 +0100, Jean-David Beyer
> <jdbeyer@exit109.com> wrote:
>
>> Enrique Perez-Terron wrote:
>
>
>>> As to the "should have been", I guess an admissible definition would
>>> consider if it fits into the framework that the maintainers of the
>>> rc.sysinit file are trying to implement; that lets the software issue
>>> the right modprobe commands on all relevant installations of the
>>> distribution; that is, something that could be contributed to the
>>> maintainer. If maintainers accept it, you don't have to worry about
>>> it the next time you upgrade the initscripts package.
>>
>>
>> I do not see why the system maintainers should accept it. I might as well
>> build the sg module into the kernel. And some people do not want or
>> need it,
>> so why should they be stuck with it. I am convinced it does not belong in
>> /etc/rc.d/rc/sysinit. Of course,
>> /sbin/modprobe floppy
>> is in there too, and I do not think it belongs.
>
>
> The idea is this: The distro is readied by some guys and distributed,
> then it lands on a few tens of thousands of different computers. The
> distro cannot embody knowledge like "this computer has a PleXTor cd
> burner connected to a scsi controller", but it can embody "if the
> running computer does have so-and-so, load module sg - unless it is
> compiled in."

N.B.: this is not really a CD-R[W] issue at all.

The system does not create ANY of the /dev/sg entries, and it should be
creating at least four of them. One for each of the SCSI hard drives, one
for the SCSI tape drive. All three of these are on one SCSI controller.
And one for the PlexTor CD-R[W] drive that is on a separate SCSI controller
of its own. It seems to me that it should automatically generate the
/dev/sg* nodes if it generates the regular device nodes, and it does not.

So the Red Hat and CentOS guys should have said that if you have SCSI
devices, you should conjure up both the regular device nodes; e.g.,
/dev/sda, and the sg nodes; e.g., /dev/sg0/ (irrespective of what those
devices might be, unless there is some knowledge that some devices never
require the /dev/sg* nodes, and I do not think it would be worth their
trouble to make a table of all devices since they cannot be known in advance
anyway).
>
> This is what makes the distro "run out of the box" for most users.
>
> In the bad old days, all device discovery happened at boot time; devices
> did not come and go in the middle of the uptime. All logic to decide
> what modules to load did hang off rc.sysinit. It did not have to reside
> entirely in rc.sysinit, but could be in programs run by rc.sysinit.

My RHEL3 system is from the "bad old days" in that if you make nodes in /dev
they stay there and work. And at least in Red Hat, no later than when the
system is installed, it creates all needed nodes in /dev (and lots more,
actually).
>
> With the advent of USB particularly, devices began appearing and
> disappearing as never before. (I know, pcmcia and cardbus has been
> around a while, but I believe USB is what finally sparked the current
> evolution in the device handling. Wireless technologies like Bluetooth
> also accentuated the need.)
>
> So the hotplug system was invented, and much of the device-module logic
> moved into it. That move of course left many Unix/Linux oldtimers like
> myself mystified: Why do these /dev files pop up out of nowhere? And
> when the /dev files for some reason don't materialize, where on earth do
> I look to correct it? So also with the modules. To this day I have
> not seen a good description of how this works, other than small pieces
> written in a language from Jupiter, describing the relations between the
> sixth and seventh cogwheel.
>
>>> My understanding of the current udev architecture is that, as the kernel
>>> enumerates buses and devices, it creates nodes in /sys/devices/*
>>> exporting
>>> attributes of the devices, and it invokes the program named in
>>> /proc/sys/kernel/hotplug with some data about the device placed in the
>>> program's environment.
>>
>>
>> I do not know who creates the stuff in /sys/devices, but my sg3 is in
>> there
>> somewhere. I found it.
>
>
> The kernel does!!

That is not what I meant. What executable file or program asks the kernel to
do it?
>
> The /sys directory is empty, actually, (or any contents get hidden by
> the mount), but rc.sysinit mounts a "sysfs" filesystem there. That
> is a virtual file system, nothing is written to disk, just like /proc
> and procfs. There is no "device" mounted, the "device" argument to
> the mount command is any dummy word.
>
> In the scsi.agent script you see "/sys$DEVPATH", because the decision
> to mount the sysfs on just "/sys" is a userland decision, the kernel
> does not know that in advance. But the value of DEVPATH is entirely
> determined by the kernel, and exported to userland in the environment
> of the program named in /proc/sys/kernel/hotplug. The sysfs is there
> precisely to give the userland something to go on when figuring out
> what modules to load and what device node files to create.
>
> This is why I suggest you explore the contents of the files in the
> directory node you found, to see what does the kernel reveal about the
> device, upon which a decision could be based.

I thought I listed them all, and they indicate that the directory node I
found agree perfectly with what I would expect to be there if it described
the Plextor device.

But I repeat, this is not a Plextor problem at all. It is a problem with ALL
my SCSI devices on both controllers. Whatever generates the /dev nodes is
not generating the sg devices, only the "regular" ones.
>
>> $ cat /proc/sys/kernel/hotplug
>> /sbin/hotplug
>>
>>>
>>> For devices being hotplugged after the system has booted, the set of
>>> programs
>>> and scripts invoked from the hotplug program, embodies the knowledge
>>> about
>>> what modules should be loaded. Once a module is loaded, its
>>> initialization may
>>> produce further hotplug events.
>>
>>
>> Now the system at some point comes up with
>> /dev/scd0 which is the read-only aspect of the CD-ROM burner.
>> But it does not come up with
>> /dev/sg3 which is the write aspect of the CD-ROM burner.
>
>
> There is a file in the Documentation directory of the kernel source, about
> the sg driver:
>
> The SCSI Generic driver (sg) is one of the four "high level" SCSI device
> drivers along with sd, st and sr (disk, tape and CDROM respectively). Sg
> is more generalized (but lower level) than its siblings and tends to be
> used on SCSI devices that don't fit into the already serviced categories.
> Thus sg is used for scanners, CD writers and reading audio CDs digitally
> amongst other things.
>
> From this, I wonder if there is any generic way to determine from what
> the kernel sees on the bus, and exports in /sys/devices, if the sg driver
> is required.

Unless there are a few exceptions, it seems to me that ALL SCSI devices also
need the sg driver in case an application program needs to use it. So, IMAO,
any machine with SCSI devices needs the sg module loaded no later than just
before the first application needs to use it so that the /dev/sg nodes are
present.

> In the world of USB devices, there is a notion of "class",
> allowing device producers to mark their devices in a way that allows
> the kernel to figure out what to do. I just don't know that much about
> scsi, if there is any equivalent.
>
> It seems possible at this point that the only generic way is to put the
> "modprobe sg" in rc.local, with or without a test for the contents of
> the "model" file in the /sys/devices node (I don't know what it contains.
> For what I know, it could be a string identifying the device, or it could
> be a number, which has to be looked up in a directory. Or perhaps it does
> not identify the device at all.)
>
> **Update** I see you tell this below. Also see /proc/sys/dev/cdrom/info,
> which I discovered below.**
>
> But looking around some more, I find some rules in /etc/hotplug/rules.d/*
> (line breaks with "\" are by me):
>
> KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", \
> PROGRAM=="/etc/udev/scripts/check-cdrom.sh %k CD-R",
> SYMLINK="cdwriter%e"
> KERNEL=="sr[0-9]*", BUS=="scsi", \
> PROGRAM=="/etc/udev/scripts/check-cdrom.sh %k CD-R",
> SYMLINK="cdwriter%e"
>
> KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", \
> PROGRAM="/etc/udev/scripts/check-cdrom.sh %k DVD-R",
> SYMLINK="dvdwriter%e"
> KERNEL=="sr[0-9]*", BUS=="scsi", \
> PROGRAM=="/etc/udev/scripts/check-cdrom.sh %k DVD-R",
> SYMLINK="dvdwriter%e"
>
> # rename sr* to scd*
> KERNEL=="sr[0-9]*", BUS=="scsi", NAME="scd%n"
> KERNEL=="hd[a-z]*", BUS=="ide", SYSFS{removable}=="1",
> NAME{ignore_remove}="%k"
>
> This seems to point to an ability to determine if a device is a cd writer,
> in which case it seems that loading "sg" is appropriate, according to the
> quote above.

Loading sg is appropriate for ALL scsi devices, since you never know when an
application will need to use it (them).
>
> Looking at /etc/udev/scripts/check-cdrom.sh, it turns out to read /proc/
> sys/dev/cdrom/info. Another surprise. On my system, cat
> /proc/sys/dev/cdrom/info:
>
> CD-ROM information, Id: cdrom.c 3.20 2003/12/17
>
> drive name: hdd
> drive speed: 32
> drive # of slots: 1
> Can close tray: 1
> Can open tray: 1
> Can lock tray: 1
> Can change speed: 1
> Can select disk: 0
> Can read multisession: 1
> Can read MCN: 1
> Reports media changed: 1
> Can play audio: 1
> Can write CD-R: 1
> Can write CD-RW: 1
> Can read DVD: 0
> Can write DVD-R: 0
> Can write DVD-RAM: 0
> Can read MRW: 1
> Can write MRW: 1
> Can write RAM: 1
>
> Is there similar information on your system?

$ cat /proc/sys/dev/cdrom/info
CD-ROM information, Id: cdrom.c 3.20 2003/12/17

drive name: sr0 hdc
drive speed: 32 40
drive # of slots: 1 1
Can close tray: 1 1
Can open tray: 1 1
Can lock tray: 1 1
Can change speed: 1 1
Can select disk: 0 0
Can read multisession: 1 1
Can read MCN: 1 1
Reports media changed: 1 1
Can play audio: 1 1
Can write CD-R: 1 0
Can write CD-RW: 1 0
Can read DVD: 0 0
Can write DVD-R: 0 0
Can write DVD-RAM: 0 0
Can read MRW: 1 1
Can write MRW: 1 1
Can write RAM: 1 1

$ ls -l /dev/cdrom
lrwxrwxrwx 1 root root 3 Dec 3 13:06 /dev/cdrom -> hdc
(this is the regular CD-ROM drive; could be 40x)

valinuxl:jdbeyer[~]$ ls -l /dev/cdrom1
lrwxrwxrwx 1 root root 4 Dec 3 13:06 /dev/cdrom1 -> scd0
(this is the Plextor CD-R[W] drive; is 32x).

$ ls -l /dev/sr0
ls: /dev/sr0: No such file or directory

$ ls -l /dev/scd0
brw-rw---- 1 root disk 11, 0 Dec 3 13:06 /dev/scd0
(this is the Plextor CD-R[w] drive.)
>
>> But that SCSI controller is always on; i.e., it is an internal SCSI Host
>> Adapter card plugged into a PCI bus slot.
>>
>> Now with RHL 7.3 and RHL 9, the kernel did not notice the SCSI burner
>> unless
>> it was powered on during kernel boot. I assume this is still true, so I
>> always leave the unit powered on, even though I do not use it much.
>> Otherwise, if power fails and the UPS initiates a controlled shutdown,
>> and
>> power comes back and the system reboots, no CD-ROM burner. Now I do
>> not know
>> if powering on the CD-ROM burner amounts to hot plugging in the sense
>> that
>> the kernel will look and see if I just did that. I am assuming it does
>> not.
>
>
> Hard to say except by trying. I guess scsi wasn't invented with hotplug
> in mind, so there may not be anything there that invokes the kernel's
> hotplug
> mechanisms.

I tried powering the Plextor off and on, and the machine did not notice
anything.
>
>>> For devices discovered before userland is available, and specifically
>>> before
>>> rc.sysinit writes a program path into /proc/sys/kernel/hotplug,
>>
>>
>> ??? The string "/proc/sys/kernel/hotplug" does not exist in my rc.sysinit
>> file. It also does not appear in any file in /etc/sysconfig. or
>> /etc/rc.d/init.d.
>
>
> Yes, ???.
>
> On my system, rc.sysinit:
>
> # Initialize hardware
> if [ -f /proc/sys/kernel/modprobe ]; then
> if ! strstr "$cmdline" nomodules && [ -f /proc/modules ] ; then
> sysctl -w kernel.modprobe="/sbin/modprobe" >/dev/null 2>&1
> sysctl -w kernel.hotplug="/sbin/udevsend" >/dev/null 2>&1
> else
> # We used to set this to NULL, but that causes 'failed to exec'
> messages"
> sysctl -w kernel.modprobe="/bin/true" >/dev/null 2>&1
> sysctl -w kernel.hotplug="/bin/true" >/dev/null 2>&1
> fi
> fi
>
> If yours is similar, you'll have to leave out "/proc/sys/" from the regexp.
>
>>> From what you have written so far, I am under the impression that the
>>> current initscripts do discover the device, and do create /dev entries,
>>> but not of the right kind, and do not load the sg module. Once the
>>> module
>>> is loaded, the system does correctly create the /dev/sg* nodes.
>>
>>
>> The entries do discover the CDROM aspects of the device and create the
>> /dev/scd0
>> entry. But they do not discover the CD-R[W} aspects of the device and
>> do not
>> create
>> /dev/sg3
>>
>> They do not create any /dev/sg entries, not for my two SCSI hard
>> drives, my
>> SCSI tape drive, nor my CD-R[W] drive. So whatever is the matter, it
>> is more
>> serious than just the CD-R[W] drive.
>>
>> In fact, it seems to me that if any SCSI module is loaded, which seems
>> the
>> purpose of scsi.agent, it should always load the sg driver as well. But
>> should I modify the scsi-agent file to do this? That seems to be a bad
>> idea.
>> Should not the loading of any scsi module cascade the loading of the sg
>> module as well?
>
>
> If /proc/sys/dev/cdrom does contain the necessary information, you could
> add
> a test for it in scsi.agent. Or write to your distro's maintainers
> (bugzilla?)
> and elicit some thoughts. I can't imagine they don't want to have cd
> burners
> work "out of the box".

No SCSI device works out of the box if you need the /dev/sg* nodes. This is
not just a SCSI CD burner problem. It is also a SCSI disk problem and a SCSI
tape problem. And probably all SCSI device problem.
>
>>>
>>> This makes me believe that the script you posted, scsi.agent is being
>>> run
>>> with the relevant device, but this script fails to embody the correct
>>> knowledge of what modules should be loaded. You mentioned the
>>> possibility
>>> of adding a branch to the "case" statement "case $TYPE" of...esac",
>>> if only you knew what the value of TYPE is for your device. The script
>>> loads this variable with the contents of a file /sys$DEVPATH/type.
>>
>>
>> Well, I looked in /usr/include/scsi/scsi.h and that shows, in part,
>>
>> /*
>> * DEVICE TYPES
>> */
>>
>> #define TYPE_DISK 0x00
>> #define TYPE_TAPE 0x01
>> #define TYPE_PROCESSOR 0x03 /* HP scanners use this */
>> #define TYPE_WORM 0x04 /* Treated as ROM by our system */
>> #define TYPE_ROM 0x05
>> #define TYPE_SCANNER 0x06
>> #define TYPE_MOD 0x07 /* Magneto-optical disk -
>> * - treated as TYPE_DISK */
>> #define TYPE_MEDIUM_CHANGER 0x08
>> #define TYPE_ENCLOSURE 0x0d /* Enclosure Services Device */
>> #define TYPE_NO_LUN 0x7f
>>
>> which sorta-kinda matches this part of scsi.agent:
>>
>> TYPE=$(cat $TYPE_ATTR)
>> case "$TYPE" in
>> # 2.5.51 style attributes; <scsi/scsi.h> TYPE_* constants
>> 0) TYPE=disk ; MODULE=sd_mod ;;
>> # FIXME some tapes use 'osst' not 'st'
>> 1) TYPE=tape ; MODULE=st ;;
>> 2) TYPE=printer ; MODULE=sg ;;
>> 3) TYPE=processor ; MODULE=sg ;;
>> 4) TYPE=worm ; MODULE=sr_mod ;;
>> 5) TYPE=cdrom ; MODULE=sr_mod ;;
>> 6) TYPE=scanner ; MODULE=sg ;;
>> 7) TYPE=mod ; MODULE=sd_mod ;;
>> 8) TYPE=changer ; MODULE=sg ;;
>> 9) TYPE=comm ; MODULE=sg ;;
>> 14) TYPE=enclosure ; MODULE=sg ;;
>> esac
>> if [ "$MODULE" != "" ]; then
>> mesg "$TYPE at $DEVPATH"
>> modprobe $MODULE
>> else
>> debug_mesg "how to add device type=$TYPE at $DEVPATH ??"
>> fi
>> ;;
>>
>> but if that is anything to go by, this won'd do either as there is no
>> entry
>> for "CDRW" or whatever it might be called.
>
>
> It seems that the "type" more or less covers the functionality of
> "class" in
> USB, but that the classification is not adequate to decide if sg should
> be loaded
> or not.
>
Actually, modifying this script would be very tricky. If the spirit of this
script is to be observed, it would have to be called twice in the case of
scsi devices. Once to do what it now does, and again to add the sg module.
Actually, the best way would be to add, after the "fi"; after the case stuff
was done and the module selected in there was loades, to have just

modprobe sg

since ALL SCSI devices need the sg module.

Or somewhere in the behavior of modprobe should be diddled so loading
sd_mod, sr_mod, st would FORCE the loading of sg.

So where are module dependencies listed? I know about
/lib/modules/2.6.9-22.0.1.ELsmp/modules.dep. The one for sg is

/lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi/sg.ko: \
/lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi/scsi_mod.ko

and the one for sr_mod is

/lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi/sr_mod.ko: \
/lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi/scsi_mod.ko

and the one for scsi_mod is

/lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi/scsi_mod.ko:

Maybe if this one (or these) also included a dependency on the sg.ko, this
stuff all would work. How do I influence the dependencies in this table? I
suppose /sbin/depmod.

But according to man depmod, it gets its information from the modules
themselves, and unless the modules themselves ask for sg, they do not get it
into the modules.dep file. And the modules themselves do not realize the
need for sg since they do not need it themselves; it is just that anyone
using the system and needing the sg module need it, and you can infer that
pretty easily if there are SCSI controllers in the system.
>
>
>>> I suggested you could look and see if you could find this file, first
>>> determining which directory in the /sys/devices tree corresponds to
>>> your dvd burner,
>>
>>
>> That would be this:
>>
>> ./0000:00:12.0/host1/target1:0:4/1:0:4:0:
>> total 0
>> lrwxrwxrwx 1 root root 0 Dec 4 15:30 block ->
>> ../../../../../../block/sr0
>> --w------- 1 root root 4096 Dec 4 15:30 delete
>> -rw-r--r-- 1 root root 4096 Dec 4 15:30 detach_state
>> -r--r--r-- 1 root root 4096 Dec 4 15:30 device_blocked
>> -rw-r--r-- 1 root root 4096 Dec 4 15:30 dump
>> lrwxrwxrwx 1 root root 0 Dec 4 15:30 generic ->
>> ../../../../../../class/scsi_generic/sg3
>> -r--r--r-- 1 root root 4096 Dec 4 15:30 model
>> drwxr-xr-x 2 root root 0 Dec 3 13:06 power
>> -r--r--r-- 1 root root 4096 Dec 4 15:30 queue_depth
>> --w------- 1 root root 4096 Dec 4 15:30 rescan
>> -r--r--r-- 1 root root 4096 Dec 4 15:30 rev
>> -r--r--r-- 1 root root 4096 Dec 4 15:30 scsi_level
>> -rw-r--r-- 1 root root 4096 Dec 4 15:30 state
>> -rw-r--r-- 1 root root 4096 Dec 4 15:30 timeout
>> -r--r--r-- 1 root root 4096 Dec 4 15:30 type
>> -r--r--r-- 1 root root 4096 Dec 4 15:30 vendor
>>
>>> and then cat'ing the file "type" from this directory.
>>
>>
>> [/sys/devices/pci0000:00/0000:00:12.0/host1/target1:0:4/1:0:4:0]$ cat
>> type
>> 5
>>
>> Well, "5" is true, as far as it goes, but it should also be something
>> else
>> to get me both the
>>
>> 5) TYPE=cdrom ; MODULE=sr_mod ;;
>>
>> and someting else to get me something like this:
>>
>> 126) TYPE=cdrw ; MODULE=sg ;;
>>
>> in there.
>
>
> Agreed.
>
>
>>> You seemed to find a directory node that could be the right one,
>>> but I don't know what more you did to pursue that. You focused a symlink
>>> to /dev/sg3, probably as a reason to believe this was the right node.
>>> You could also look at the contents of other files in the node, e.g.
>>> "model", to see if you find further evidence that this is indeed the
>>> right node.
>>
>>
>> [/sys/devices/pci0000:00/0000:00:12.0/host1/target1:0:4/1:0:4:0]$ cat
>> model
>> CD-R PX-W1210S
>>
>> This seems correct as it is one way my device identifies itself.
>>
>> [/sys/devices/pci0000:00/0000:00:12.0/host1/target1:0:4/1:0:4:0]$ cat
>> vendor
>> PLEXTOR
>>
>> This is the correct vendor, and I have nothing else from PLEXTOR on my
>> machine.
>>
>>>
>>> I still don't know for sure if scsi.agent is being run with environment
>>> variables pointing to the cd burner.
>>
>>
>> It seems to me that it is, since it creates the /dev/scd0 node which is
>> required when an existing CD-ROM is in there and I want to mount it.
>
>
> Having a couple of burns from earlier quick assumptions, I prefer to add
>
> echo "$0" "$@" >> /dev/mylog
> set >> /dev/mylog
>
> to the scsi.agent file, and look for /dev/mylog after next reboot.
>
> There seems to be code in /etc/rules.d/* to create the /dev/scd* nodes.
>
> I have not investigated what execution paths lead to the
> /etc/hotplug.d/default/default.hotplug which in turn seems to reference
> scsi.agent.
>
>
>
> I still wonder if there is a program like "kmodule" on your system, and
> what
> exactly it does. In my rc.sysinit:
>
> echo -n $"Initializing hardware... "
>
> ide=""
> scsi=""
> network=""
> audio=""
> other=""
> eval `kmodule -d | while read devtype mod ; do
> case "$devtype" in
> "IDE") ide="$ide $mod"
> echo "ide=\"$ide"\";;
> "SCSI") scsi="$scsi $mod"
> echo "scsi=\"$scsi"\";;
> "NETWORK") network="$network $mod"
> echo "network=\"$network"\";;
> "AUDIO") audio="$audio $mod"
> echo "audio=\"$audio"\";;
> *) other="$other $mod"
> echo "other=\"$other"\";;
> esac
> done`
>
> load_module () {
> LC_ALL=C fgrep -xq "$1" /etc/hotplug/blacklist 2>/dev/null ||
> modprobe $1 >/dev/null 2>&1
> }
>
> # IDE
> for module in $ide ; do
> load_module $module
> done
>
> # SCSI
> for module in `/sbin/modprobe -c |
> LC_ALL=C awk '/^alias[[:space:]]+scsi_hostadapter[0-9]*[[:space:]]/
> { print $3 }'` $scsi; do
> load_module $module
> done
> load_module floppy
>
> echo -n $" storage"
>
> kmodule belongs to the initscripts rpm package. I happen to have the
> initscrips source rpm installed, but the functionality of kmodule turns
> out to be in libkudzu. The documentation is wonderfull: zero doc files.
>
> How does one determine if a driver is compiled-in? By the absence of
> the module in /lib/modules/$(uname -r)/* ? Any better?
>
> -Enrique


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 09:35:00 up 8 days, 20:05, 4 users, load average: 4.19, 4.26, 4.25

On Mon, 05 Dec 2005 16:27:50 +0100, Jean-David Beyer <jdbeyer@exit109.com> wrote:

> N.B.: this is not really a CD-R[W] issue at all.
>
> The system does not create ANY of the /dev/sg entries, and it should be
> creating at least four of them. One for each of the SCSI hard drives, one
> for the SCSI tape drive. All three of these are on one SCSI controller.
> And one for the PlexTor CD-R[W] drive that is on a separate SCSI controller
> of its own. It seems to me that it should automatically generate the
> /dev/sg* nodes if it generates the regular device nodes, and it does not.
>
> So the Red Hat and CentOS guys should have said that if you have SCSI
> devices, you should conjure up both the regular device nodes; e.g.,
> /dev/sda, and the sg nodes; e.g., /dev/sg0/ (irrespective of what those
> devices might be, unless there is some knowledge that some devices never
> require the /dev/sg* nodes, and I do not think it would be worth their
> trouble to make a table of all devices since they cannot be known in advance
> anyway).

Oh, I have been assuming all along that only specific devices actually needed
the sg driver. If we work from this point of veiw, it should be simple,
anywhere any of the scsi "highlevel" drivers are loaded, load the sg module
too. Your sugestion towards the end of the message seems fair enough.


>>> I do not know who creates the stuff in /sys/devices, but my sg3 is in
>>> there
>>> somewhere. I found it.
>>
>>
>> The kernel does!!
>
> That is not what I meant. What executable file or program asks the kernel to
> do it?

None! Or so I believe. I have the understanding that all kernel bus
drivers set up nodes in /sys for their buses, and probe the buses for
devices and automatically add further nodes for each device found.

E.g, in drivers/scsi/scsi_scan.c there is the function
scsi_probe_and_add_lun(), which, unless there is an error,
calls scsi_add_lun(), which allocates the kernel structures that
constitute the kernel's awareness of the lun. Unless there is
an error, it unconditionally calls scsi_sysfs_add_sdev(), which
adds the device node to the sysfs filesystem.

>> This is why I suggest you explore the contents of the files in the
>> directory node you found, to see what does the kernel reveal about the
>> device, upon which a decision could be based.
>
> I thought I listed them all, and they indicate that the directory node I
> found agree perfectly with what I would expect to be there if it described
> the Plextor device.

Yes, you are right. I found it further down the page.

>> Is there similar information on your system?
>
> $ cat /proc/sys/dev/cdrom/info
> CD-ROM information, Id: cdrom.c 3.20 2003/12/17
>
> drive name: sr0 hdc
> drive speed: 32 40
> drive # of slots: 1 1
> Can close tray: 1 1
> Can open tray: 1 1
> Can lock tray: 1 1
> Can change speed: 1 1
> Can select disk: 0 0
> Can read multisession: 1 1
> Can read MCN: 1 1
> Reports media changed: 1 1
> Can play audio: 1 1
> Can write CD-R: 1 0
> Can write CD-RW: 1 0
> Can read DVD: 0 0
> Can write DVD-R: 0 0
> Can write DVD-RAM: 0 0
> Can read MRW: 1 1
> Can write MRW: 1 1
> Can write RAM: 1 1

Interesting. However, assuming everybody agrees that sg should always
be loaded, it is no longer so important to look up here and see if the
device is a burner.

If people disagree, here is a possible source of configuration. Only
one caveat for this, will this /proc file show the same info *before*
sg is loaded?

> $ ls -l /dev/cdrom
> lrwxrwxrwx 1 root root 3 Dec 3 13:06 /dev/cdrom -> hdc
> (this is the regular CD-ROM drive; could be 40x)
>
> valinuxl:jdbeyer[~]$ ls -l /dev/cdrom1
> lrwxrwxrwx 1 root root 4 Dec 3 13:06 /dev/cdrom1 -> scd0
> (this is the Plextor CD-R[W] drive; is 32x).
>
> $ ls -l /dev/sr0
> ls: /dev/sr0: No such file or directory

From what we see in the rules.d/* file, inside the kernel the device
is called sr0, but the rules file renames it to scd0.

>
> $ ls -l /dev/scd0
> brw-rw---- 1 root disk 11, 0 Dec 3 13:06 /dev/scd0
> (this is the Plextor CD-R[w] drive.)


>> Hard to say except by trying. I guess scsi wasn't invented with hotplug
>> in mind, so there may not be anything there that invokes the kernel's
>> hotplug
>> mechanisms.
>
> I tried powering the Plextor off and on, and the machine did not notice
> anything.

How would you notice if the machine had noticed?

The situation may also be different from booting with the device powered
off and then powering it on.

I discovered that my computer is perfectly aware of the presence of my
USB printer even if the printer has the power cord pulled out. I can
plug in the usb cable, and unplug it again, and the device nodes nodes
are created and removed, and lsusb (and /proc/bus/usb/devices contents)
all change. But then the usb technology has been designed with a margin
of power in the cable sufficient to activate the interface electronics.

I imagine that USB is more "modern" in this respect than scsi.

[ about /etc/hotplug/scsi.agent ]

> Actually, modifying this script would be very tricky. If the spirit of this
> script is to be observed, it would have to be called twice in the case of
> scsi devices. Once to do what it now does, and again to add the sg module.
> Actually, the best way would be to add, after the "fi"; after the case stuff
> was done and the module selected in there was loades, to have just
>
> modprobe sg
>
> since ALL SCSI devices need the sg module.

Given the premise, I agree.

> Or somewhere in the behavior of modprobe should be diddled so loading
> sd_mod, sr_mod, st would FORCE the loading of sg.
>
> So where are module dependencies listed? I know about
> /lib/modules/2.6.9-22.0.1.ELsmp/modules.dep. The one for sg is
>
> /lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi/sg.ko: \
> /lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi/scsi_mod.ko
>
> and the one for sr_mod is
>
> /lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi/sr_mod.ko: \
> /lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi/scsi_mod.ko
>
> and the one for scsi_mod is
>
> /lib/modules/2.6.9-22.0.1.ELsmp/kernel/drivers/scsi/scsi_mod.ko:
>
> Maybe if this one (or these) also included a dependency on the sg.ko, this
> stuff all would work. How do I influence the dependencies in this table? I
> suppose /sbin/depmod.
>
> But according to man depmod, it gets its information from the modules
> themselves, and unless the modules themselves ask for sg, they do not get it
> into the modules.dep file. And the modules themselves do not realize the
> need for sg since they do not need it themselves; it is just that anyone
> using the system and needing the sg module need it, and you can infer that
> pretty easily if there are SCSI controllers in the system.

To force a dependency in the modules, one would add a dummy variable or so,
and reference it from the other modules. I.e., modify the modules themselves.

But I don't know enough about the functionality offered by each module
(or by the scsi protocol itself) to have any opinion about the appropriateness
of always loading sg.

-Enrique

Enrique Perez-Terron wrote:
> On Mon, 05 Dec 2005 16:27:50 +0100, Jean-David Beyer
> <jdbeyer@exit109.com> wrote:
>
>> N.B.: this is not really a CD-R[W] issue at all.
>>
>> The system does not create ANY of the /dev/sg entries, and it should be
>> creating at least four of them. One for each of the SCSI hard drives, one
>> for the SCSI tape drive. All three of these are on one SCSI controller.
>> And one for the PlexTor CD-R[W] drive that is on a separate SCSI
>> controller
>> of its own. It seems to me that it should automatically generate the
>> /dev/sg* nodes if it generates the regular device nodes, and it does not.
>>
>> So the Red Hat and CentOS guys should have said that if you have SCSI
>> devices, you should conjure up both the regular device nodes; e.g.,
>> /dev/sda, and the sg nodes; e.g., /dev/sg0/ (irrespective of what those
>> devices might be, unless there is some knowledge that some devices never
>> require the /dev/sg* nodes, and I do not think it would be worth their
>> trouble to make a table of all devices since they cannot be known in
>> advance
>> anyway).
>
>
> Oh, I have been assuming all along that only specific devices actually
> needed
> the sg driver. If we work from this point of veiw, it should be simple,
> anywhere any of the scsi "highlevel" drivers are loaded, load the sg module
> too. Your sugestion towards the end of the message seems fair enough.
>
That sort of depends on what applications you are running. But the
applications should not be loading and unloading modules, and I do now want
to re-write cdrecord (for the Plextor) or VXAtool (proprietary source
anyway, so I cannot, for the Tape drive). The tape drive normally just uses
/dev/st0 and /dev/nst0, but if there is an error, a program called VXAtool
can be invoked that diagnoses the hard drive and writes a file.
>
[snip]

>>> Is there similar information on your system?
>>
>>
>> $ cat /proc/sys/dev/cdrom/info
>> CD-ROM information, Id: cdrom.c 3.20 2003/12/17
>>
>> drive name: sr0 hdc
>> drive speed: 32 40
>> drive # of slots: 1 1
>> Can close tray: 1 1
>> Can open tray: 1 1
>> Can lock tray: 1 1
>> Can change speed: 1 1
>> Can select disk: 0 0
>> Can read multisession: 1 1
>> Can read MCN: 1 1
>> Reports media changed: 1 1
>> Can play audio: 1 1
>> Can write CD-R: 1 0
>> Can write CD-RW: 1 0
>> Can read DVD: 0 0
>> Can write DVD-R: 0 0
>> Can write DVD-RAM: 0 0
>> Can read MRW: 1 1
>> Can write MRW: 1 1
>> Can write RAM: 1 1
>
>
> Interesting. However, assuming everybody agrees that sg should always
> be loaded, it is no longer so important to look up here and see if the
> device is a burner.
>
> If people disagree, here is a possible source of configuration. Only
> one caveat for this, will this /proc file show the same info *before*
> sg is loaded?

I do not know and cannot find out without rebooting that machine.
I suspect it is the same, since /dev/sc