On Thu, 24 Dec 2009, Andy Green wrote: > Here's what I understood your proposed scheme would look like for a user > going through a typical flow: > > 1) Device powers up with g_file_storage module loaded, but the shared > filesystem is mounted on the device > > 2) User opens files from the shared storage on device > > 3) User randomly plugs USB cable into host <=== actual trigger > > 4) Userspace on device is magically aware of the plugin somehow > without using netlink, runs a script killing apps with files open from > shared storage, umounts it, sets the backing file for g_file_storage > using the sysfs file > > 5) Host sees we have some media > > 6) Host mounts shared storage, pops up file manager > > 7) User does storage tasks and ejects <=== actual trigger > > 8) Device userspace is magically aware of the ejection action in > g_file_storage without using netlink, and remounts the shared storage on > the device, starts apps or whatever it likes to do then > > >> So > >> whatever we do, we need netlink notification that's going on so we can > >> run our userland script to do its thing, same deal when he ejects we > >> need the netlink notification to remount. So I guess we agree so far? > > > > No. You don't need netlink notification because the trigger is an > > event occurring in userspace, not an event occurring in the kernel. > > Userspace already knows what's going on; the kernel doesn't have to > > tell it anything. > > This is not so in the flow shown above? How did userspace become aware > that the device got plugged into a host running a mass storage class > stack (and that the device is configured for mass storage mode and not > g_ether). The genuine trigger there is the act of being plugged into > the host surely. Yes. That's different from what you were talking about before. Several people have requested notifications from the kernel as to when a gadget's USB cable is plugged in or unplugged. This is completely separate from g-file-storage; it should be handled at the level of the device controller driver. After all, people using other kinds of gadget drivers will want to receive these notifications too. And it's still true that you don't need arbitration when the cable is plugged in or unplugged. (The question of which gadget driver is loaded -- g_file_storage vs. g_ether -- can already be answered using the information available in sysfs.) That's step 4. As for step 8, I agreed earlier that it might be nice to have some sort of notification scheme for when the host ejects the medium. Isn't sysfs_notify() good enough? You don't need any sort of arbitration for ejects. > >> Can you give me a clue where the right place to move the "host is trying > >> to use us" netlink notification would be then? Right now it's done the > >> first time the host tries to read and write us since connection or eject. > > > > There is no right place to move the netlink notification, because it > > isn't needed to begin with. > > That's where I don't follow you at all. > > Maybe when you have a minute you can edit the flow I wrote above to fill > in the gaps in my understanding. Do the comments above help? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
