I think I get what happens - the implementation must be holding on to the
device path protocol, the by_driver fails so we try the by_driver|exclusive
which then triggers the disconnectcontroller logic internally which isn't
protocol specific and just stops whatever it is, in this case the file
system driver which also provided the handle/device path attempting to be
opened so then it fails to open after that (and there is no handle now for
connectcontroller - you'd need to trigger that on the parent). But I've
concluded there is probably no way under the current implementation/model
of UEFI to have both the ability to open block/disk protocols that won't go
away without our consent and be able to use the simple file system protocol
at the same time. You either have to kick off the file system while you
have a protocol open or open the protocol in a way that can disappear
without our knowledge due to hot-swap. There are also issues if you say
have block io open by_driver|exclusive then want to open the disk io
driver which (probably) wants the block io protocol itself (so it fails,
which means you have to open unsafe method which means the disk io protocol
can go away, even though the block io protocol is safe, at least the spec
seems to read that it's per protocol the driver model).
On Mon, Sep 16, 2013 at 8:23 PM, David F. <df7...@gmail.com> wrote:
> .. while I can remember .. Under OVMF (would guess it's using shared code
> others would be), if you have a EFI_SIMPLE_FILE_SYSTEM_PROTOCOL you want to
> try and coexist with direct access to drive in a way safe from hot-swap
> there are issue. If you attempt to open that device path (returned with
> LocateHandleBuffer searching for Block IO devices) in BY_DRIVER|EXCLUSIVE
> under driver model, it will disappear and that protocol can no longer be
> found. Same occurs if you open Block IO2 exclusive or Block IO
> exclusive. If you exit the app and from the shell try map -r, it also
> can't find it. Seems no way to get it back except to reboot. If you
> don't try to do things in a hot-swap safe way then there are no problems
> (expect of course if a drive is "open" and the block io protocol is being
> used and the drive is removed, that protocol (memory structure) is no
> longer valid and everything crashes). It be nice if everything could just
> get along...
>
>
> On Mon, Sep 16, 2013 at 6:26 PM, David F. <df7...@gmail.com> wrote:
>
>> Hi,
>>
>> I open exclusive access to the device path for a given block io device.
>> I want to ensure the structure (protocol) doesn't go away while in a
>> routine. Meanwhile a support routine will take a handle to a mounted file
>> system on that same block io device and attempt to use the
>> DevicePathFromHandle support routine which uses HandleProtocol but it fails
>> with INVALID_PARAMETER. The two protocols have nothing to do with each
>> other other than the same device, so why would it fail to get the device
>> path of the file system (different handles)? If I change it to not be
>> exclusive but to be BY_HANDLE_PROTOCOL on the block io device then the
>> DevicePathFromHandle will return the device path to the partition.
>>
>>
>>
>
------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
