From: Menachem Shapiro <menachem.shapiro_at_gmail.com>
Date: Mon, 14 May 2007 18:40:41 -0700

B"H
On 5/14/07, Nix <nix_at_esperi.org.uk> wrote:
> On 14 May 2007, Menachem Shapiro verbalised:
> > I would love to get feedback on the script, as well as any help
> > regarding udev integration. I tried different things using
> > ATTRS{idProduct} and ATTRS{idVendor}
> > [http://www.rockbox.org/twiki/bin/view/Main/DeviceDetection], but it
> > is the first time I have ever tried messing around with udev, and I
> > couldn't get it to work.
>
> Regarding udev integration, what did you try?

I created a file called 98-rockbox.rules and put it in
/etc/udev/rules.d. I experimented with different things, trying to use
the VID and PID of the usb device as an identifier. I ended up with
something like tihs:
SUBSYSTEM=="usb", ATTRS{idVendor}=="05ab", ATTRS{idProduct}=="0060",
RUN+="/home/mshapiro/rockbox_scripts/rockbox_downloader.sh"

From your helpful information below, it looks like I am trying to use
the wrong block to identify the device, which is probably why it
wouldn't work. I was hoping to use the VID and PID of the device as an
identifier, since that information is unique to the device, but that
may not be possible. I will try out different things and report how it
went.

Menachem

>
> You can determine the right keys to use fairly easily because udev can
> tell you most of what to do. Find your device's block device, and try,
> e.g.
>
> # udevinfo -a -p /sys/block/sdc
>
> (I have some SCSI disks on this machine so sda and sdb were already
> taken; the iPod got sdc).
>
> You get a bunch of output, structured into blocks.
>
> All but the latest udev releases (098 and later) can only match single
> blocks (`looking at...' sections) at once, so all the keys have to come
> from one block. The key names also differ in udev 098 and later, but the
> names given by udevinfo will always be correct for your udev release.
>
> ,----
> | Udevinfo starts with the device specified by the devpath and then
> | walks up the chain of parent devices. It prints for every device
> | found, all possible attributes in the udev rules key format.
> | A rule to match, can be composed by the attributes of the device
> | and the attributes from one single parent device.
> |
> | looking at device '/block/sdc':
> | KERNEL=="sdc"
> | SUBSYSTEM=="block"
> | DRIVER==""
> | ATTR{stat}==" 23044 7258 30475 1022020 3331 1475 660281 40332280 0 1063280 41354300"
> | ATTR{size}=="58605120"
> | ATTR{removable}=="1"
> | ATTR{range}=="16"
> | ATTR{dev}=="8:32"
>
> This block (corresponding to the block device itself) is probably not worth matching against.
>
> | looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1/1-1/1-1:1.0/host9/target9:0:0/9:0:0:0':
> | KERNELS=="9:0:0:0"
> | SUBSYSTEMS=="scsi"
> | DRIVERS=="sd"
> | ATTRS{ioerr_cnt}=="0x0"
> | ATTRS{iodone_cnt}=="0x7af6"
> | ATTRS{iorequest_cnt}=="0x7af6"
> | ATTRS{iocounterbits}=="32"
> | ATTRS{timeout}=="30"
> | ATTRS{state}=="running"
> | ATTRS{rev}=="1.62"
> | ATTRS{model}=="iPod "
> | ATTRS{vendor}=="Apple "
> | ATTRS{scsi_level}=="0"
> | ATTRS{type}=="0"
> | ATTRS{queue_type}=="none"
> | ATTRS{queue_depth}=="1"
> | ATTRS{device_blocked}=="0"
> | ATTRS{max_sectors}=="240"
>
> This one looks more interesting: it's the iPod's SCSI interface, and
> it's a block device (SUBSYSTEMS=scsi is a bit of a giveaway). It's not
> actually a *mountable* device as such, but it owns all the partitions so
> a match against it will get fired for all its children (the individual,
> mountable partitions) as well. I match against this via
>
> SUBSYSTEMS=="scsi", ATTRS{model}=="iPod", ATTRS{vendor}=="Apple", KERNEL=="sd?2", SYMLINK+="ipod", GROUP="dosdisks"
>
> and, well, bingo, I now have a /dev/ipod symlink. Add a RUN= key to that
> and you should be home free. `udevtest' can be useful to see what would happen
> if you plugged the iPod in; `udevmonitor' can be useful to spy on udev and
> see what *does* happen.
>
> | looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1/1-1/1-1:1.0/host9/target9:0:0':
> | KERNELS=="target9:0:0"
> | SUBSYSTEMS==""
> | DRIVERS==""
> |
> | looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1/1-1/1-1:1.0/host9':
> | KERNELS=="host9"
> | SUBSYSTEMS==""
> | DRIVERS==""
> |
> | looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1/1-1/1-1:1.0':
> | KERNELS=="1-1:1.0"
> | SUBSYSTEMS=="usb"
> | DRIVERS=="usb-storage"
> | ATTRS{modalias}=="usb:v05ACp1209d0001dc00dsc00dp00ic08isc06ip50"
> | ATTRS{bInterfaceProtocol}=="50"
> | ATTRS{bInterfaceSubClass}=="06"
> | ATTRS{bInterfaceClass}=="08"
> | ATTRS{bNumEndpoints}=="02"
> | ATTRS{bAlternateSetting}==" 0"
> | ATTRS{bInterfaceNumber}=="00"
>
> These blocks are probably also not worth matching on, not least because they
> don't correspond to disks, so if you tried to make a SYMLINK to them you'd
> get a symlink to a USB endpoint device: not so terribly useful to mount!
>
> | looking at parent device '/devices/pci0000:00/0000:00:04.2/usb1/1-1':
> | KERNELS=="1-1"
> | SUBSYSTEMS=="usb"
> | DRIVERS=="usb"
> | ATTRS{serial}=="000A27001566DEDA"
> | ATTRS{product}=="iPod"
> | ATTRS{manufacturer}=="Apple"
> | ATTRS{quirks}=="0x0"
> | ATTRS{maxchild}=="0"
> | ATTRS{version}==" 2.00"
> | ATTRS{devnum}=="21"
> | ATTRS{speed}=="12"
> | ATTRS{bMaxPacketSize0}=="64"
> | ATTRS{bNumConfigurations}=="1"
> | ATTRS{bDeviceProtocol}=="00"
> | ATTRS{bDeviceSubClass}=="00"
> | ATTRS{bDeviceClass}=="00"
> | ATTRS{bcdDevice}=="0001"
> | ATTRS{idProduct}=="1209"
> | ATTRS{idVendor}=="05ac"
> | ATTRS{bMaxPower}=="500mA"
> | ATTRS{bmAttributes}=="c0"
> | ATTRS{bConfigurationValue}=="1"
> | ATTRS{bNumInterfaces}==" 1"
> | ATTRS{configuration}==""
>
> This looks potentially useful, but again, the SUBSYSTEMS is a usb
> endpoint. There's no point trying to mount this.
>

<snip>

>
> Anyway, I hope you see the general trick of it. It's quite easy to get
> used to once you've managed to get a few things working :)
>
Received on 2007-05-15