Re: [PATCH] [g_mass_storage] Fix unmount problem with OS-X

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/23/2012 09:20 AM, Alan Stern wrote:
> On Wed, 23 May 2012, Pantelis Antoniou wrote:
>
>> On May 23, 2012, at 6:11 PM, Alan Stern wrote:
>>
>>> On Thu, 24 May 2012, Pantelis Antoniou wrote:
>>>
>>>> OS-X uses a sequence on unmounting that makes us close the backing
>>>> file.
>>> What do you mean?  Does OS-X send an eject command (as far as I know, 
>>> that's the only command that will cause the backing file to be closed)?
>>>
>> OS-X does sent an eject command.
> Okay.  It has every right to do so.
>
>>>> Apparently there's no way to open it again, which makes it
>>>> impossible to remount without rmmod'ing g_mass_storage.
>>> That's not true at all.  If the backing file has been closed, it can be 
>>> re-opened (or another file can be opened in its place) by writing the 
>>> filename to the gadget's "file" attribute in sysfs.
>>>
>> Arguably that's not what you want, nor you expect. 
>>
>> Linux doesn't sent the eject command so when you reconnect the cable the 
>> original configuration (i.e. the old mass storage file) is used.
>>
>> Without this you need to either rmmod, or rewrite the filename to the gadget's
>> "file" attribute whenever the host umounts sending an eject command.
>>
>> So what we have is this:
>>
>> Linux host unmounts, backing file is not closed, disk will appear when
>> another mount command is issued, without having to write the "file" 
>> attribute in sysfs.
>>
>> Mac OS X host unmounts, backing file is closed, disk will not appear
>> since no mount command can be issued, because the backing file is closed.
>> Only if the gadget's "file" attribute in sysfs is written, or module is 
>> rmmod'ed & insmod'ed again will a mount command work.
> Yes, that all sounds right.
>
>> I'm open to suggestions that will make OS X behave in the same manner as
>> Linux.
> Then may I suggest that you write to the developers at Apple and send
> them your advice?  Clearly nothing we do here in the linux-usb mailing
> list will change OS-X's behavior.  :-)
>
> Seriously, if the host OS sends an eject command then we have to assume
> that this is what the user really wants.  Suppose that instead of a
> mass-storage gadget, an actual USB storage device had been plugged in,
> like one of the old ZIP drives.  When OS-X sends it an eject command,
> it will eject its cartridge.  After that, no mount command will work
> until the user puts a new cartridge in the drive.  That's exactly how
> the mass-storage gadget behaves.

Media that can physically eject is not the only media that is marked
removable and can accept an eject command. And you mention 'what the
user really wants'. If a very popular OS is sending 'eject' to removable
media when the user instructs it to unmount, I'm pretty sure the user
still wants it to function when they unplug the device and then go plug
it in somewhere else.
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux