Tim, Agreed - When BaseTools gets the standalone support I expect us to be able to differentiate library instances.
I wanted to gather feedback now while we prototype on a branch. Eugene > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > Of Tim Lewis > Sent: Friday, September 30, 2016 10:56 AM > To: Cohen, Eugene <eug...@hp.com>; Laszlo Ersek > <ler...@redhat.com>; edk2-devel@lists.01.org <edk2- > de...@ml01.01.org>; Kinney, Michael D > <michael.d.kin...@intel.com>; Yao, Jiewen <jiewen....@intel.com>; > Andrew Fish (af...@apple.com) <af...@apple.com> > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol > and Handle Services > > Eugene -- > > Since the standalone file type isn't yet in the EDK2 code, the build > system will not be able to make this distinction in the library's INF file. > > Tim > > > -----Original Message----- > From: Cohen, Eugene [mailto:eug...@hp.com] > Sent: Friday, September 30, 2016 9:51 AM > To: Tim Lewis <tim.le...@insyde.com>; Laszlo Ersek > <ler...@redhat.com>; edk2-devel@lists.01.org <edk2- > de...@ml01.01.org>; Kinney, Michael D > <michael.d.kin...@intel.com>; Yao, Jiewen <jiewen....@intel.com>; > Andrew Fish (af...@apple.com) <af...@apple.com> > Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol > and Handle Services > > Tim, > > My focus at the moment is on standalone SMM drivers, but in order to > support the dual-mode DXE_SMM_DRIVER modules we could have > another instance that does the InSmm check at runtime. > > Eugene > > > -----Original Message----- > > From: Tim Lewis [mailto:tim.le...@insyde.com] > > Sent: Friday, September 30, 2016 10:41 AM > > To: Cohen, Eugene <eug...@hp.com>; Laszlo Ersek > <ler...@redhat.com>; > > edk2-devel@lists.01.org <edk2- de...@ml01.01.org>; Kinney, > Michael D > > <michael.d.kin...@intel.com>; Yao, Jiewen > <jiewen....@intel.com>; > > Andrew Fish (af...@apple.com) <af...@apple.com> > > Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol > > and Handle Services > > > > Eugene -- > > > > Since SMM drivers today are actually DXE drivers during the > > initialization phase, are you going to (a) have your library check > > InSmm? or (b) only work with pure SMM stand-alone drivers? > > > > Thanks, > > > > Tim > > > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On > Behalf Of > > Cohen, Eugene > > Sent: Friday, September 30, 2016 9:37 AM > > To: Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org > > <edk2-de...@ml01.01.org>; Kinney, Michael D > > <michael.d.kin...@intel.com>; Yao, Jiewen > <jiewen....@intel.com>; > > Andrew Fish (af...@apple.com) <af...@apple.com> > > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol > > and Handle Services > > > > Laszlo, > > > > > As far as I know: > > > - the DXE and SMM protocol databases are distinct, > > > - the same protocol GUID may or may not be installed (on one or > > more) > > > handle(s) in either, > > > - even if a protocol GUID exists uniquely in exactly one of those > > > databases, the locator function would have to return which > database > > > the GUID was found. > > > > > > My point is that every wrapper function that returns a protocol > > > interface (or several protocol interfaces), or handles, each such > > > return value will likely have to be qualified with the database > > > where > > it was found. > > > > The intent here is to only search the UEFI DB from a DXE/UEFI driver > > and the SMM DB from an SMM driver and not to cross between. So > which > > protocol DB is searched is purely a function of the module type (i.e. > > what instance of the ProtocolLib it was linked against). This is > > analogous to what is done with MemoryAllocationLib which either > > allocates from the UEFI memory pools for UEFI/DXE modules > > (UefiMemoryAllocationLib instance) or from the SMM memory pools > for > > SMM modules (SmmMemoryAllocationLib). > > > > Sorry I wasn't more clear initially. > > > > Eugene > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
