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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).