dbus/udisks guru? Import record should store information about card

[Jason Gerard DeRose]

The import record should store information about the SD/SDHC/CF card being imported from. This provides a rich audit trail for pro use.

Information should be extracted using the udisks Device interface - http://hal.freedesktop.org/docs/udisks/Device.html

We primarily want to extract information about the disk, not the partition. An example of the sort of information we want to extract:

size: 16005169152
vendor: Lexar
model: CFUDMASD
revision: 1000
serial: AA0000000009019

[Manish Sinha (मनीष सिन्हा) (manishsinha)]

Are you sure to use udisk? I have actually never heard about this.

I would recommend udev to query it (Don't believe blindly in me, I have pretty much less idea)

$ udevadm info -a -p $(udevadm info -q path -n /dev/sdb)

You get

Udevadm info 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 '/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0/block/sdb':
    KERNEL=="sdb"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{range}=="16"
    ATTR{ext_range}=="256"
    ATTR{removable}=="0"
    ATTR{ro}=="0"
    ATTR{size}=="976773168"
    ATTR{alignment_offset}=="0"
    ATTR{discard_alignment}=="0"
    ATTR{capability}=="50"
    ATTR{stat}==" 3369 73783 402729 83260 0 0 0 0 0 35968 83252"
    ATTR{inflight}==" 0 0"

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0':
    KERNELS=="6:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{device_blocked}=="0"
    ATTRS{type}=="0"
    ATTRS{scsi_level}=="3"
    ATTRS{vendor}=="Seagate "
    ATTRS{model}=="Portable "
    ATTRS{rev}=="0130"
    ATTRS{state}=="running"
    ATTRS{timeout}=="30"
    ATTRS{iocounterbits}=="32"
    ATTRS{iorequest_cnt}=="0xd5a"
    ATTRS{iodone_cnt}=="0xd5a"
    ATTRS{ioerr_cnt}=="0x20"
    ATTRS{modalias}=="scsi:t-0x00"
    ATTRS{evt_media_change}=="0"
    ATTRS{dh_state}=="detached"
    ATTRS{queue_depth}=="1"
    ATTRS{queue_type}=="none"
    ATTRS{max_sectors}=="240"

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host6/target6:0:0':
    KERNELS=="target6:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host6':
    KERNELS=="host6"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0':
    KERNELS=="1-1:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb-storage"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bNumEndpoints}=="02"
    ATTRS{bInterfaceClass}=="08"
    ATTRS{bInterfaceSubClass}=="06"
    ATTRS{bInterfaceProtocol}=="50"
    ATTRS{modalias}=="usb:v0BC2p2300d0130dc00dsc00dp00ic08isc06ip50"
    ATTRS{supports_autosuspend}=="0"

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb1/1-1':
    KERNELS=="1-1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="80"
    ATTRS{bMaxPower}=="100mA"
    ATTRS{urbnum}=="10360"
    ATTRS{idVendor}=="0bc2"
    ATTRS{idProduct}=="2300"
    ATTRS{bcdDevice}=="0130"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="480"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="13"
 ...

[Jason Gerard DeRose (jderose)]

I'm pretty sure udisks is the way to go. It uses udev under the hood... udisks just provides a well defined dbus API, other niceties.

The last time I did this sort of thing, HAL was still the thing to use. But now that HAL is deprecated, udisks is what has replaced its storage-related functionality.

udisks is part of the DeviceKit project - http://www.freedesktop.org/wiki/Software/DeviceKit

[Manish Sinha (मनीष सिन्हा) (manishsinha)]

FYI HAL has been deprecated in favour of DeviceKit an DeviceKit has been deprecated in favour of udev.

After googling I found DeviceKit (and not uev)under the hood of udisks

To add upto the confusion, here is what I got
http://lists.freedesktop.org/archives/devkit-devel/2009-December/000567.html

[Jason Gerard DeRose (jderose)]

David,

Thanks again for all the work you've been doing on this. When you originally proposed the other udisk merge, I didn't have time to dig into the details as much as I wanted to... but you solved lot of tricky problems, so thanks for blazing the trail on this!

I've been experimenting a bit on getting this information using Python3 and PyGI, which I finally got working here:

http://bazaar.launchpad.net/~dmedia/dmedia/trunk/view/head:/misc/udisks-test.py

And I discovered something unfortunate... at least with the card readers I have, udisks isn't giving me the DriveSerial of the card, it's giving me the DriveSerial of the card *reader*... which is worthless as far as the accounting we'd like to do.

I don't know if this is a bug in udisks that could be fixed, or it might even be an issue with the card readers I have... like they're greedy and report there own info instead of the card's. Dunno.

Oh, another hiccup is that it's tricky to find out the physical device info for a ecryptfs home partition. I came up with a work around that seems pretty reliable, but it's probably not the best solution.

So are you busy with school again now?

Cheers!

[Jason Gerard DeRose (jderose)]

David, so I'm going to close this as Fix Released. Starting with what you had, I do have this basically working now, although because of either some issues with UDisks or the particular card readers I have, it's not really accomplishing what we wanted it to... in my case, UDisks is providing the serial number of the card reader, not the card, which is kinda lame.

I'll open another bug to address this.

Anyway, thanks again for all your work on this... when I said this was "bite-size", I don't know what I was smoking. This was "super-size" :P

Also, I pretty much left your implementation as is because I figure just in case we need to use any of this under Python2 still... and I felt a bit bad messing up your code as I stumbled through getting DBus working with PyGI.

Oh, and as we currently aren't getting a meaningful ID for a card or partition on a card, I'm not creating the drive or partition documents in CouchDB. I think we do probably want them, but I'd like to let that idea slow-roast longer, see how useful it proves once we have correct data from UDisks.

[Jason Gerard DeRose (jderose)]

Big thanks to @dobey for finding this blog post that confirms it is indeed a hardware issue that apparently all USB card readers suffer from:

http://www.bunniestudios.com/blog/?p=918#comment-510692