On Wed, Oct 14, 2015 at 05:19:32AM +0000, Ye, Ting wrote: > Hi all, > > If I understand the issue correctly, I don't quite agree that UEFI > spec is imprecise about SNP constraints described as following. > The "constraint" described here is that the grub should use attribute > "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage > is clearly described in page 184, chapter 6.3 > EFI_BOOT_SERVICES.OpenProtocol(). > > EXCLUSIVE Used by applications to gain exclusive access to a > protocol interface. > If any drivers have the protocol interface opened with > an attribute of BY_DRIVER, > then an attempt will be made to remove them by calling > the driver's Stop() function. > > The grub code should not assume that the SNP is not occupied by other > drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to > be more precise, use OpenProtocolInformation() to check whether SNP is > already opened by other driver, then decide whether need to use EXCLUSIVE > to disconnect the other drivers. This is the typical usage for all UEFI > protocol, not particular constraints to SNP protocol.
Looks good! Great! However, it looks that we still have a problem if somebody opens SNP in EXCLUSIVE mode. Then GRUB2 SNP open will fail according to UEFI spec. Sadly we do not have a control on other stuff and one day our approach may fail because somebody decided to open SNP in EXCLUSIVE mode in e.g. a driver. Does it mean that migration to MNP is one sensible solution for our problems? As I know this is huge overhaul, so, we should think twice before choosing that way. Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel