On Fri, Nov 09, 2018 at 06:35:02PM +0000, Jeff Brasen wrote: > > 1. Add new ArmScmiClock2Protocol.h + guid > > 2. Add new guid and document that you have to use that guid for the > > enable function > > 3. Add new guid under old name and have the old guid installed on > > the handle as well, this would keep things fairly clean but > > would have a guid that wouldn't map to a protocol in header > > form. > > 4. Just change the protocol without changing the guid, this has > > the reverse issue of the change I made (except errors can > > result in a crash) (don't really like this option) > > I think my (quite puritan) preference would be > 5. Add another guid, describe it in the same .h file. > > For example, see (among several others) > EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL/EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL > in MdePkg/Include/Protocol/FirmwareVolumeBlock.h. > (This may be what you mean by 2?) > > [JB] Yes this was what I was thinking with #2
OK, cool, then we're on the same page. > It's a bit of a sledgehammer, but it is a well known and common > pattern in edk2. > > However, if we do this, I would prefer to take the opportunity to add > any new functions not already implemented at the same time. Do you > know if we have other missing calls? > > Now, this _isn't_ a protocol described by any external specification, > so we don't need to be quite as rigid as for public interfaces. > Basically, there shouldn't be (non-debug/non-devtool) dynamic > applications making use of this protocol in the first place. (If we > think there should be, we need to document this GUID and protocol in a > spec somewhere.) > So in reality, I think 4 would also be a valid thing to do. > > But I do want feedback from the original author. > > [JB] Sounds good, I think Girish is out of office until 11/21 Yeah. I'd take feedback from Sami as well :) But both me and Ard will be at plumbers next week, and we are expecting the stable tag to happen then as well - so that is basically lost anyway. Regards, Leif _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
