Enrique Perez-Terron wrote:
> On Fri, 02 Dec 2005 18:10:53 +0100, Jean-David Beyer
> <jdbeyer@exit109.com> wrote:
>
>> Enrique Perez-Terron wrote:
>>
>>> On Fri, 02 Dec 2005 13:44:15 +0100, Jean-David Beyer
>>> <jdbeyer@exit109.com> wrote:
>>>
>>>> I am having trouble running cdrecord on CentOS 4.2.
>>>>
>>>> The first problem is that it wants to use the /dev/sg* devices to
>>>> control the CD-ROM burner that is a PleXWriter 12/10/30S that is
>
> [..]
>
>>> Let cdrecord have a chance to show what it can do with the ata
>>> interface.
>>>
>> How is it going to do that when the cd-rom burner _really is a scsi
>> device_, a PleXWriter 12/10/30S on a Symbios SYM20810 PCI to Fast SCSI
>> Host Adapter? As a practical matter, what it shows it can do is try to
>> drive my ATA cd-rom read-only drive on ide3, and that will not do at
>> all.
>
>
> Ouch, my bad. I confused two things you said and came two think that the
> ide3 drive was the device you were talking about.
>
> It seems like the suggeston to load the sg module was much closer.
> However, the canonical way to configure that...
>
> I tried to make sense of the udev documentation a few weeks ago, but I
> ran out of steam. Trying again, and a bit confused about what I really
> remember, or just though ought to be...
>
> Check the file /proc/sys/kernel/hotplug. On my system it contains
> "/sbin/udevsend".

On my system (CentOS 4.2), it is:

/sbin/hotplug

There is a man page for hotplug.
It refers me to /etc/hotplug and in there is a file scsi.agent that contains:

#!/bin/sh
#
# SCSI hotplug agent for 2.5 kernels
#
# ACTION=add
# DEVPATH=devices/scsi0/0:0:0:0
#

cd /etc/hotplug
.. ./hotplug.functions

case $ACTION in

add)
# 2.5.50 kernel bug: this happens sometimes
if [ ! -d /sys/$DEVPATH ]; then
mesg "bogus sysfs DEVPATH=$DEVPATH"
exit 1
fi

TYPE_ATTR=/sys$DEVPATH/type

# Possibly sleep here to try and avoid races with scsi attributes and block
# devices
count=10
while [ ! -f $TYPE_ATTR -a $count -gt 0 ]
do
# We seem to always hit this now, so don't output any message.
debug_mesg "waiting for $TYPE_ATTR"
sleep 1
count=$(($count-1))
done

if [ ! -f $TYPE_ATTR ]
then
mesg "Attribute $TYPE_ATTR does not exist"
exit 1
fi

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

*)
debug_mesg SCSI $ACTION event not supported
exit 1
;;

esac

Now if I knew what number code I would get, or what $TYPE_ATTR I would get
for my cd-rom burner, I could just put a line in there that said, e.g.,

10) TYPE=cdromburner ; MODULE=sg ;;

in there.

> When there are hotplug events (like device
> discoveries) the kernel runs this program with some info about the event
> in environment variables.
>
> For devices that are discovered early during the kernel initialization,
> at a time when userland may not yet be available... I don't remember
> clearly, can anyone tell, is there something in /etc/rc.d/rc.sysinit for
> this?
>
> Hm, looking through rc.sysinit, it does not seem so. It looks like there
> is an undocumented program "kmodule" in the initscripts package (is this
> redhat/fedora specific?) that finds the names somehow of scsi adapters,
> ide devices... and calls modprobe a couple of times. It seems like these
> modprobe calls leads to the hotplug events that triggers the rest:
>
> /sbin/udevsend starts /sbin/udevd, a daemon, unless it already runs. Then
> it sends it a message. /sbin/udevd somehow reorders events that arrive
> close in time, and starts the program /sbin/udev with each.

At the present moment, udevd is running (according to pstree).
>
> /sbin/udev reads the files in /etc/udev/rules.d These contain "rules"
> consisting of attribute name-value pairs called "keys" in the manpage.
> The manpage fails to tell which pairs are inputs and which are outputs.
> However, when a rule is found whose input keys match the actual
> attributes of the event (as delivered in the environment? the manpage
> does not say), the output keys control actions by the udev. The actions
> are basicly RUN=... to run a program, NAME=... to create a device file in
> /dev with OWNER=, GROUP=, MODE= output attributes; create SYMLINK=s in
> /dev...
>
> To learn about what input attributes can be used to write your own rules
> for the scsi cd burner, peruse the directories in /sys (provided your
> system mounts a sysfs filesystem there). For example, I have a Lexmark
> printer and scanner, and tried this:
>
> $ cd /sys/devices
> $ (find . type f | xargs grep -i lexmark) 2>/dev/null
> ./pci0000:00/0000:00:14.2/usb1/1-1/1-1.2/product:Lexmark All-in-One
> ./pci0000:00/0000:00:14.2/usb1/1-1/1-1.2/manufacturer:Lexmark
> ./pci0000:00/0000:00:14.2/usb1/1-1/1-1.1/manufacturer:Lexmark
>
> $ udevinfo -p /sys/devices/pci0000:00/0000:00:14.2/usb1/1-1/1-1.2 -a
>
> udevinfo starts with the device the node belongs to and then walks up the
> device chain, to print for every device found, all possibly useful
> attributes in the udev key format. Only attributes within one device
> section may be used together in one rule, to match the device for which
> the node will be created.
>
> looking at class device
> '/sys/devices/pci0000:00/0000:00:14.2/usb1/1-1/1-1.2':
> SUBSYSTEM=="unknown" SYSFS{bConfigurationValue}=="1"
> SYSFS{bDeviceClass}=="00" SYSFS{bDeviceProtocol}=="00"
> SYSFS{bDeviceSubClass}=="00" SYSFS{bMaxPacketSize0}=="8"
> SYSFS{bMaxPower}==" 4mA" SYSFS{bNumConfigurations}=="1"
> SYSFS{bNumInterfaces}==" 1" SYSFS{bcdDevice}=="0100"
> SYSFS{bmAttributes}=="c0" SYSFS{configuration}=="" SYSFS{devnum}=="4"
> SYSFS{idProduct}=="0069" SYSFS{idVendor}=="043d"
> SYSFS{manufacturer}=="Lexmark" SYSFS{maxchild}=="0"
> SYSFS{product}=="Lexmark All-in-One" SYSFS{speed}=="12" SYSFS{version}=="
> 1.10"
>
> Man 8 udev should tell the rest.
>
> This is purely a guess on my part: install a call to modprobe anywhere
> you like, e.g., in /etc/rc.d/rc.local, but use the udev machinery to set
> up the /dev nodes.

I do not have to set up the /dev nodes. As soon as I load the sg module,
with

/sbin/modprobe sg

the /dev nodes are created.

> If on Fedora/Redhat, there is a file
> /etc/sysconfig/modules where you could name the module, instead of using
> rc.local.

There is no /etc/sysconfig/modules file in CentOS 4.2.
I do not want to use rc.local.
I have stuck
>
> I am not sure I would bother to do it the "politially correct" way.
>


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