On Thu, 24 Dec 2009, Andy Green wrote: > On 12/23/09 22:30, Somebody in the thread at some point said: > > Hi Alan - > > >> For these reasons an actual handshake that can return an accept or fail > >> response seems like the right way. > > > > But if you do all the arbitrarily complicated app-specific actions > > _before_ loading the new medium instead of _after_, there's no need to > > worry about arbitration. For example, you could try to unmount a > > filesystem and detect that the unmount failed because of open files. > > Then because of the failure, you could avoid loading the new medium. > > Sorry to be dense, lack of familiarity with scsi here is not giving that > explanation the intended resonance. Think of real devices with removable media. For example: a card reader, a cdrom drive, a floppy drive, or a ZIP drive. g_file_storage emulates their behavior. The host can eject the media whenever it wants (well, it can with a cdrom or ZIP drive). But new media has to be inserted by the user; the computer can not automatically insert a new card, cdrom, floppy disk, or ZIP cartridge. Instead of physical media, you are "inserting" in g_file_storage a disk partition containing a filesystem. For example, let's say you are using /dev/sdb3. > One way or another the decision to try to umount the shared storage is > triggered by the host PC trying to use the device as mass storage. Right there -- that's your mistake. The decision should be made when the user (or a program) loads the media, i.e., writes "/dev/sdb3" to the LUN's "file" atttribute. Any filesystem on /dev/sdb3 should be unmounted before doing the write. In the vast majority of cases, the host PC will access this shared storage within a second or so of the time the write takes place, so it's understandable why you might think the host access is the trigger. But it isn't; the write to the "file" attribute is the trigger. > 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. > Since the critical umount script can fail or succeed or timeout, we do > need to inform g_file_storage about the result somehow. I think you > might be telling that it's better to do that using the "test" sysfs that > lets us remove and change the backing storage to do that. No. You don't need to inform g_file_storage about any test results. All you need to do is avoid writing "/dev/sdb3" to the "file" attribute if the umount script fails. > If that's the idea, I would still call it an arbitration handshake. For > sure you know this code way better than I do :-) so if I am on the right > understanding of what you're saying, you think it will all hang together > with the host rescanning us when we use the "test sysfs" to have it use > the backing file. I don't understand what you mean by "test sysfs", but it doesn't matter. Your question is inappropriate because your basic assumptions are wrong. > The existing module code loads up the medium at bind time regardless. > So we would need to stop giving it a default medium on the module option > and only provide pre-umounted backing file through the sysfs if I > understood. That's right. You don't have to provide any backing file at all when loading g_file_storage. For example, you can do: modprobe g_file_storage removable=y This is equivalent to plugging in a cdrom drive with no CD loaded, or a card reader with no card plugged in. > 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. 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
