On 06/05/2015 07:19 PM, Andrew Fish wrote:
>
>> On Jun 5, 2015, at 5:13 PM, Laszlo Ersek <ler...@redhat.com> wrote:
>>
>> On 06/06/15 01:57, Roy Franz wrote:
>>
>>> So, the link problem I am having is in the device path conversion code
>>> (DevicePathTo/FromText.c),
>>> so is there a way to avoid this by just not supporting nice text
>>> device paths? From my (again limited)
>>> understanding of device paths, I could do something like:
>>> VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)
>>> instead of VenTtyTerm(), which would directly encode the GUID, and
>>> hence avoid the dependency problems
>>> I'm having. It will make for a more ugly .dsc file, but that's what
>>> comments are for :)
>>> Would this work?
>>
>> Absolutely. It should not be VenHw(), but VenMsg() -- grep the
>> MdePkg/Library/UefiDevicePathLib/ directory for "VenVt100", and check
>> the contexts of the hits --, but that's it. Therefore, simply don't
>> touch MdePkg/Library/UefiDevicePathLib/.
>>
>
> The emulators have a similar issue, they have non standard GUID’ed device
> paths.
>
> The way to solve this is to have a Extension Lib that UefiDevicePathLib
> depends on. The MdePkg could have the NULL version of this lib, and then a
> given platform could publish an extension lib that knows about the extra
> GUIDs.
That would be helpful. We've had to resort to modifying MdePkg locally.
--
Brian J. Johnson
--------------------------------------------------------------------
My statements are my own, are not authorized by SGI, and do not
necessarily represent SGI’s positions.
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
