On Feb 12, 2013, at 1:08 PM, "David F." <df7...@gmail.com> wrote:
> Are you saying in an application:
>
> OpenProtocol(Handle, &gEfiDiskIoProtocolGuid, (void**) &DiskIO,
> ImageHandle, NULL, EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL)
>
> is not safe - it will still invalidate the pointers in DiskIO when
> removed and won't wait until CloseProtocol is used?
>
You need to use BY_DRIVER to be safe. The AgentHandle would point to your
EFI_DRIVER_BINDING_PROTOCOL instance and EFI_DRIVER_BINDING_PROTOCOL.Stop()
will get called at the right spot when the surprise disconnect happens. The
ControlHandle can point to Handle.
The history here is EFI 1.0 was rushed out to sync up with the first Itanium
platforms. EFI 1.10 came along later and added the driver model. So for example
OpenProtocol() (and the rest of that chapter) did not exist in EFI 1.0, but
HandleProtocol() did. So BY_HANDLE_PROTOCOL maps to the old EFI 1.0 no hot-plug
behavior.
So the library in the patch hides all this and converts it to:
SafeHandle = SafeBlockIoOpen (Handle, NULL);
...
Status = SafeBlockIoRead (SafeHandle, Lba, BufferSize, &Buffer);
....
SafeBlockIoClose (SafeHandle);
If you get EFI_NO_MAPPING you know a surprise hot-unplug happened and your
application can do the right thing.
Thanks,
Andrew Fish
/**
Locates the installed BlockIo protocol instance for the handle. Usage
information
is registered in the protocol data base.
@param UserHandle The handle to obtain the protocol interface on
@param StopEvent Event that is signaled if the protocol is
stopped
@retval A pointer to the library handle that represents the opened protocol
or NULL on failure.
**/
SAFE_BLOCK_IO_HANDLE *
EFIAPI
SafeBlockIoOpen (
IN EFI_HANDLE UserHandle,
IN EFI_EVENT StopEvent OPTIONAL
);
/**
Read BufferSize bytes from Lba into Buffer.
@param Entry The library handle returned from SafeBlockIoOpen()
@param Lba The starting Logical Block Address to read from
@param BufferSize Size of Buffer, must be a multiple of device block size.
@param Buffer A pointer to the destination buffer for the data. The
caller is
responsible for either having implicit or explicit
ownership of the buffer.
@retval EFI_SUCCESS The data was read correctly from the device.
@retval EFI_DEVICE_ERROR The device reported an error while performing
the read.
@retval EFI_NO_MEDIA There is no media in the device.
@retval EFI_MEDIA_CHANGED The MediaId does not matched the current device.
@retval EFI_BAD_BUFFER_SIZE The Buffer was not a multiple of the block size
of the device.
@retval EFI_INVALID_PARAMETER The read request contains LBAs that are not
valid,
or the buffer is not on proper alignment.
@retval EFI_NO_MAPPING Protocol is no longer availible
**/
EFI_STATUS
EFIAPI
SafeBlockIoRead (
IN SAFE_BLOCK_IO_HANDLE *Entry,
IN EFI_LBA Lba,
IN UINTN BufferSize,
OUT VOID *Buffer
);
EFI_STATUS
EFIAPI
SafeBlockIoClose (
IN SAFE_BLOCK_IO_HANDLE *Entry
);
> On Tue, Feb 12, 2013 at 12:19 PM, Andrew Fish <af...@apple.com> wrote:
>>
>> On Feb 12, 2013, at 10:48 AM, David F. <df7...@gmail.com> wrote:
>>
>>> I mean the device itself may be removed, USB hard drive, 1394, etc..
>>> I presume it would still be safe and attempts to access it would
>>> simply fail?
>>>
>>
>> The bus driver (USB Bus Driver for example) does a
>> gBS->DisconnectController() and causes the Block IO driver to stop. Stop
>> means uninstall your protocols. This works fine for the EFI driver model as
>> the leaf gets stopped first. So the file system driver first, then the
>> partition driver, and then the Block IO driver get stopped. The problem we
>> run into is the EFI application may do a HandleProtocol() and in this case
>> it will not be notified when the stack gets torn down.
>>
>> In my other mail where I attached a patch, there was a library that wraps
>> Block IO and makes it safe to use by following the driver model. Basically
>> you just call library functions and if you application is in the middle of a
>> block IO call you fail the stop. This library implements the BY_DRIVER
>> attribute of OpenProtocol() and produces a driver binding protocol instance
>> so a surprise removal request can be detected or deferred.
>>
>> This model is a side effect of some of the other rules we have. For example
>> device paths must be unique, only one instance of a protocol per handle, and
>> how the DXE core tracks all the drivers and their parent child relationships.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> On Tue, Feb 12, 2013 at 8:44 AM, Andrew Fish <af...@apple.com> wrote:
>>>> What do you mean by device being removed? Media being removed from a
>>>> device is a different case than unplugging an USB disk.
>>>>
>>>> Andrew Fish
>>>>
>>>>
>>>> On Feb 11, 2013, at 7:38 PM, "David F." <df7...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'd like to open the DISK_IO protocol and leave it open for quite a
>>>>> while (hours). In the mean time the device may be removed. I would
>>>>> assume that I can continue to try using the protocol to read/write and
>>>>> there would simply be a failure (as long as its detached - if
>>>>> something else in its place may fail due to media-id difference, but
>>>>> that is understood). Once I close the protocol, then the item is
>>>>> cleaned up.
>>>>>
>>>>> Is the assumption good?
>>>>>
>>>>> TIA!!
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Free Next-Gen Firewall Hardware Offer
>>>>> Buy your Sophos next-gen firewall before the end March 2013
>>>>> and get the hardware for free! Learn more.
>>>>> http://p.sf.net/sfu/sophos-d2d-feb
>>>>> _______________________________________________
>>>>> edk2-devel mailing list
>>>>> edk2-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Free Next-Gen Firewall Hardware Offer
>>>> Buy your Sophos next-gen firewall before the end March 2013
>>>> and get the hardware for free! Learn more.
>>>> http://p.sf.net/sfu/sophos-d2d-feb
>>>> _______________________________________________
>>>> edk2-devel mailing list
>>>> edk2-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Free Next-Gen Firewall Hardware Offer
>>> Buy your Sophos next-gen firewall before the end March 2013
>>> and get the hardware for free! Learn more.
>>> http://p.sf.net/sfu/sophos-d2d-feb
>>> _______________________________________________
>>> edk2-devel mailing list
>>> edk2-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Free Next-Gen Firewall Hardware Offer
>> Buy your Sophos next-gen firewall before the end March 2013
>> and get the hardware for free! Learn more.
>> http://p.sf.net/sfu/sophos-d2d-feb
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
