From: Todd Musall <tmusall@comcast.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: Some strange configuration behaviour using USB mass storage
Date: Sun, 18 Jul 2004 21:56:48 +0000 [thread overview]
Message-ID: <1090187808.27181.10.camel@parents> (raw)
In-Reply-To: <20040717192950.GA24198@csbd.org>
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
next prev parent reply other threads:[~2004-07-18 21:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-17 19:29 Some strange configuration behaviour using USB mass storage Alexander Poquet
2004-07-18 21:56 ` Todd Musall [this message]
2004-07-20 14:45 ` Patrick Mansfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1090187808.27181.10.camel@parents \
--to=tmusall@comcast.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.