On 12/24/09 15:47, Somebody in the thread at some point said:
Hi -
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.
Understood.
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.
Yep, understood.
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.
Yeah that is what I understood from your previous email. But I am not
sure we're talking about the same thing yet.
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.
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.
Yeah I did understand that from your last mail. I should have said "we
act different", by not mounting the medium we cause a situation the host
won't try to mount us if I understood.
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.
:-D
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.
Alright, that was understood as well then.
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.
Thanks for your time so far,
-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
