Messages in this thread | | | Subject | block: DISK_MEDIA_CHANGE uevents vs add/remove events | From | Karl Palsson <> | Date | Tue, 23 Feb 2016 16:53:04 -0000 |
| |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm trying to get userspace to properly mount/unmount a microSD card attached to a (built in) usb card reader (SMSC2640) when the card is inserted/removed from the slot. On Fedora/Gnome, this is being handled by the udisks daemon and using the uevent-hotplug debugger example from https://www.kernel.org/doc/pending/hotplug.txt and "udevadm monitor" I can see the kernel creates the two change events, and the final add event, the first change event with DISK_MEDIA_CHANGE=1 for /dev/sda, (the card reader slot), and ending with a "remove" event for /dev/sda1 (the partition itself)
I'm working on OpenWrt, without the udisks daemon, but OpenWrt's userspace is still properly handling the "add" and "remove" events and mounting/unmounting, _if_ it gets them.
However, I don't see the add or remove events there. I have to explicitly run a command that touches /dev/sda to trigger anything, and then I only get a single "change" event. (or use the in kernel polling[1])
My question is then really:
1: Why don't I get the add/remove events? Who is _really_ responsible for them? Or alternatively, is userspace _meant_ to be handling this directly from the "change" events? I see that with a CD-ROM, there are no kernel add/remove events, only change events, unlike SD cards.
Sincerely, Karl Palsson
[1] Using the "in kernel" event polling with "echo 250 > /sys/block/sda/events_poll_msecs" and then using usbmon, I can see the SCSI LUN check polling happening, and I can immediately see the uevents for "change" events. Yay. that's nice. Originally I wrote this mail while testing linux 3.18, where this _didn't_ work. But upgrading to 4.1.16 fixed this, so one less thing to worry about :)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJWzI5wAAoJEBmotQ/U1cr2iMYP/A+uDtxaRGSfwqAVInjli4kD BDZqjGnv9S3AkEMK9GWrCb6QLl/4h+YeXDVge0LPsBozaK8e5CSz+82B1ZyuZNH9 fJAxzVrsgLlg1YVf2b4Z0p2Fwa5e91qZtrBAh2IgkyEMJFUljb5+fnhYNC/09k17 EDFyF684k65Rc8o9VcvkkxxZea0BuunCFfkfWf81OnPtmvtv4yaIjSrcxRLzg1DN DCujidVZIflAIhH22+ATGqXRAXsbRqAf5rwHkNdytizHNGMdmNiFDdhzibYZNhxN YIv3EetjqcFYio7PCL10nReW7hA0mMqFSjcb0gpy+begadFpK+y7LfnDj5MOPFja 2q/jGhPyxgDmGzM9v+bZNWobWYOj/bJD9frclturJp1LiQHoh6We9sOOQ8XR8S13 aZRTGcZkBIBSU0kirEDWIsP6zVtoIkDsE/fZuV9pNTrycqlWgkr4ZY1uWuPIMW76 828gAlNI0PsiIilaAx7JZ7wUDa5WW4IQ6owSkV+uetB8Dqp4fq/UBcPWGatnD2wz KucEwtbbc54vthJjS2aHeln4qIsWPYKKWAo8orMN9KWd6A8Ohv9juWUyy6qsiZ+W zKLyOU4SyNiT46dKsXUFtozhvwfN4QkKXWaAUy1qVHbNQzebIN39DXMOaIkw2hOW 0SBGpyowQWZpE1itssvz =EH8A -----END PGP SIGNATURE-----
| |