Some strange configuration behaviour using USB mass storage

Some strange configuration behaviour using USB mass storage

[Alexander Poquet]

Hi folks.

I recently acquired a new laptop that essentially only provides USB
interfaces to the outside world.  Given udev's reputation for
facilitating persistant naming schemes, I dediced to give it a try.

I am running Debian GNU/Linux on i386.  I bought a USB cdrw/dvd drive
and attempted to write a rule to symlink /dev/cdrom and /dev/dvd
intelligently.  I succeeded, but not without a roundabout hack using
PROGRAM.  I'd like to know if this is fact the only way (due perhaps to
misbehaving hardware) or if I've missed something major.

After plugging in the drive, udev, using Debian's default ruleset,
created a /dev/sr0 device which, when mounted, gave me access to the
cdrom.

I executed the following command to get some more information:
udevinfo -a -p /sys$(udevinfo -q path -n /dev/sr0)

Which yielded a lot of stuff, notably the following:

  looking at class device '/sys/block/sr0':
    SYSFS{dev}="11:0"
    SYSFS{range}="1"
    SYSFS{size}="1224776"
    SYSFS{stat}="       8        0       32     5377        0        0
0        0        0     5377     
5377"

follow the class device's "device"
  looking at the device chain at
'/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4:1.0/host1/1:0:0:0':
    BUS="scsi"
    ID="1:0:0:0"
    SYSFS{detach_state}="0"
    SYSFS{device_blocked}="0"
    SYSFS{max_sectors}="128"
    SYSFS{model}="COMBO LSC-24082K"
    SYSFS{queue_depth}="1"
    SYSFS{rev}="JKD2"
    SYSFS{scsi_level}="3"
    SYSFS{state}="running"
    SYSFS{timeout}="0"
    SYSFS{type}="5"
    SYSFS{vendor}="Slimtype"

There was more but it didn't really pertain to the device in question so
I've cut it out in the interest of brevity.  Let me know if you want it.

At any rate, I naively wrote the following rule:
BUS="scsi", SYSFS{vendor}="Slimtype", SYSFS{model}="COMBO LSC-24082K", NAME="%k", SYMLINK="cdrom dvd", OWNER="root", GROUP="cdrom", MODE="0660"

I restarted udev and it dutifully created cdrom and dvd links, pointing
to /dev/sg0.  A character device.  Unmountable.  In restrospect, the
fact that all that information came from the second "block" output by
udevinfo should have rung a few bells.

Unfortunately, the actual block device, sr0, has essentially no features
that uniquely distinguish it, making it a poor candidate for a simple
persistant rule.  So I wrote the following hack, weird-hack.sh:

#!/bin/bash

[ -d /sys/block/$1 ] || exit 1
[ -e /sys/block/$1/device/model ] || exit 1
[ -e /sys/block/$1/device/vendor ] || exit 1
echo $(cat /sys/block/$1/device/vendor):$(cat /sys/block/$1/device/model)

... and then I wrote a new rule, which works, of course:
KERNEL="sr[0-9]", PROGRAM="/etc/udev/weird-hack.sh %k", RESULT="Slimtype:COMBO LSC-24082K", NAME="%k", SYMLINK="cdrom dvd", OWNER="root", GROUP="cdrom", MODE="0660"

What confuses me though, is why all this hoopla is necessary.  Isn't
there a better, more elegant way?

I'm a udev newbie, so I'm sure I've just overlooked something silly.
I'm not subscribed so if you could CC me that would be great.  UDEV is a
pretty nifty tool.  Thanks for all your dev efforts, and thanks in
advance for reading this.

Have a good one.
Alexander Poquet


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Some strange configuration behaviour using USB mass storage

[Todd Musall]

Alexander,

I don't have a usb cdrom/dvd drive, but I do have a usb external hard
drive.  Whenever it's powered up there's an entry in
/proc/scsi/usb-storage/1 in this case.  The device is /dev/sda1.  Inside
the file '1' is the device's name.  Couldn't you just use
PROGRAM="/bin/cat /proc/scsi/usb-storage/%n | grep 'COMBO LSC-24082K'"
to detect your device?

I use a similar rule for my cdrom like this:

# samsung ide cdrw, name it cdrom and symlink the default name
BUS="ide", KERNEL="hd?", PROGRAM="/bin/cat /proc/ide/%k/model",
RESULT="SAMSUNG CD-R/RW SW-252B", NAME="cdrom", SYMLINK="%k"

Hope this helps,
-Todd

On Sat, 2004-07-17 at 15:29, Alexander Poquet wrote:
> Hi folks.
> 
> I recently acquired a new laptop that essentially only provides USB
> interfaces to the outside world.  Given udev's reputation for
> facilitating persistant naming schemes, I dediced to give it a try.
> 
> I am running Debian GNU/Linux on i386.  I bought a USB cdrw/dvd drive
> and attempted to write a rule to symlink /dev/cdrom and /dev/dvd
> intelligently.  I succeeded, but not without a roundabout hack using
> PROGRAM.  I'd like to know if this is fact the only way (due perhaps to
> misbehaving hardware) or if I've missed something major.
> 
> After plugging in the drive, udev, using Debian's default ruleset,
> created a /dev/sr0 device which, when mounted, gave me access to the
> cdrom.
> 
> I executed the following command to get some more information:
> udevinfo -a -p /sys$(udevinfo -q path -n /dev/sr0)
> 
> Which yielded a lot of stuff, notably the following:
> 
>   looking at class device '/sys/block/sr0':
>     SYSFS{dev}="11:0"
>     SYSFS{range}="1"
>     SYSFS{size}="1224776"
>     SYSFS{stat}="       8        0       32     5377        0        0
> 0        0        0     5377     
> 5377"
> 
> follow the class device's "device"
>   looking at the device chain at
> '/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4:1.0/host1/1:0:0:0':
>     BUS="scsi"
>     ID="1:0:0:0"
>     SYSFS{detach_state}="0"
>     SYSFS{device_blocked}="0"
>     SYSFS{max_sectors}="128"
>     SYSFS{model}="COMBO LSC-24082K"
>     SYSFS{queue_depth}="1"
>     SYSFS{rev}="JKD2"
>     SYSFS{scsi_level}="3"
>     SYSFS{state}="running"
>     SYSFS{timeout}="0"
>     SYSFS{type}="5"
>     SYSFS{vendor}="Slimtype"
> 
> There was more but it didn't really pertain to the device in question so
> I've cut it out in the interest of brevity.  Let me know if you want it.
> 
> At any rate, I naively wrote the following rule:
> BUS="scsi", SYSFS{vendor}="Slimtype", SYSFS{model}="COMBO LSC-24082K", NAME="%k", SYMLINK="cdrom dvd", OWNER="root", GROUP="cdrom", MODE="0660"
> 
> I restarted udev and it dutifully created cdrom and dvd links, pointing
> to /dev/sg0.  A character device.  Unmountable.  In restrospect, the
> fact that all that information came from the second "block" output by
> udevinfo should have rung a few bells.
> 
> Unfortunately, the actual block device, sr0, has essentially no features
> that uniquely distinguish it, making it a poor candidate for a simple
> persistant rule.  So I wrote the following hack, weird-hack.sh:
> 
> #!/bin/bash
> 
> [ -d /sys/block/$1 ] || exit 1
> [ -e /sys/block/$1/device/model ] || exit 1
> [ -e /sys/block/$1/device/vendor ] || exit 1
> echo $(cat /sys/block/$1/device/vendor):$(cat /sys/block/$1/device/model)
> 
> ... and then I wrote a new rule, which works, of course:
> KERNEL="sr[0-9]", PROGRAM="/etc/udev/weird-hack.sh %k", RESULT="Slimtype:COMBO LSC-24082K", NAME="%k", SYMLINK="cdrom dvd", OWNER="root", GROUP="cdrom", MODE="0660"
> 
> What confuses me though, is why all this hoopla is necessary.  Isn't
> there a better, more elegant way?
> 
> I'm a udev newbie, so I'm sure I've just overlooked something silly.
> I'm not subscribed so if you could CC me that would be great.  UDEV is a
> pretty nifty tool.  Thanks for all your dev efforts, and thanks in
> advance for reading this.
> 
> Have a good one.
> Alexander Poquet
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click
> _______________________________________________
> Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
-- 
Todd Musall <tmusall@comcast.net>



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Some strange configuration behaviour using USB mass storage

[Patrick Mansfield]

On Sat, Jul 17, 2004 at 12:29:50PM -0700, Alexander Poquet wrote:

> At any rate, I naively wrote the following rule:
> BUS="scsi", SYSFS{vendor}="Slimtype", SYSFS{model}="COMBO LSC-24082K", NAME="%k", SYMLINK="cdrom dvd", OWNER="root", GROUP="cdrom", MODE="0660"

Both the sg and sr use the above rule, but the sg one is applied last,
overriding what you really wanted.

Try adding KERNEL="sr*" to the above.

> I restarted udev and it dutifully created cdrom and dvd links, pointing
> to /dev/sg0.  A character device.  Unmountable.  In restrospect, the
> fact that all that information came from the second "block" output by
> udevinfo should have rung a few bells.
> 
> Unfortunately, the actual block device, sr0, has essentially no features
> that uniquely distinguish it, making it a poor candidate for a simple
> persistant rule.  So I wrote the following hack, weird-hack.sh:

I don't understand the above comment, it has the vendor and model as
in the rule above, and is sr compared to sg.

-- Patrick Mansfield


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel