[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20160223153116-21767-71363-mailpile@palmtree-beeroclock-net>
Date: Tue, 23 Feb 2016 16:53:04 -0000
From: Karl Palsson <karlp@...ak.net.au>
To: axboe <axboe@...nel.dk>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc: openwrt-devel <openwrt-devel@...ts.openwrt.org>
Subject: block: DISK_MEDIA_CHANGE uevents vs add/remove events
-----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-----
Powered by blists - more mailing lists