> On Oct 14, 2015, at 4:08 AM, Daniel Kiper <daniel.ki...@oracle.com> wrote: > >> 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.
Then it is fortunate that when I wrote the MNP implementation that we ship with Oracle Solaris 11.2, that I tested it on many thousands of systems as well as on new UEFI implementations at the UEFI Plugfest ;). --S > > Daniel > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
