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