On 06/25/19 00:08, Laszlo Ersek wrote: > On 06/21/19 12:59, David Woodhouse wrote:
>> Adding a generic way for block devices to report a human-readable >> description in order to kill off all the device-type-specific functions >> in BmBootDescription.c presumably *would* involve actually coordinating >> with UEFI Specifications first? >> >> But we could consider that a second step. If I make the LegacyBm code >> just call the existing (but renamed) EfiBootManagerGetBootDescription() >> then all the horrid special cases and the specification work that's >> required to fix them are purely an implementation detail in >> EfiBootManagerLib? > > I think exposing EfiBootManagerGetBootDescription() as a public > function, as-is, is a no-brainer, if platforms need it. > > *Changing* EfiBootManagerGetBootDescription() is hairier. > UefiBootManagerLib strives for strict spec compliance (and minimalism), > if I remember correctly. However, I'm not a big fan of that approach > myself, and recently, "extend first, standardize second" has seemed more > accepted/tolerated than before. (I'm an active proponent of this latter > approach.) > > A new hook into PlatformBootManagerLib might help, either way. Please > see TianoCore#982, and commit range cef7ecf6cdb4..1010873becc5. > > So, please ask Ray (CC'd) :) Wait, we already have EfiBootManagerRegisterBootDescriptionHandler(). Could that help? Thanks, Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42761): https://edk2.groups.io/g/devel/message/42761 Mute This Topic: https://groups.io/mt/32122467/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-