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.
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. 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?
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.
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.
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.
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.
-Andy
--
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
