linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).