On 06/06/15 00:36, Roy Franz wrote:
> On Fri, Jun 5, 2015 at 2:31 AM, Ard Biesheuvel
> <ard.biesheu...@linaro.org> wrote:
>> On 5 June 2015 at 06:03, Roy Franz <roy.fr...@linaro.org> wrote:
>>> On Thu, May 14, 2015 at 1:57 PM, Kinney, Michael D
>>> <michael.d.kin...@intel.com> wrote:
>>>> Roy,
>>>>
>>>> 1) New GUID should be defined in MdeModulePkg/MdeModulePkg.dec
>>>> 2) New include file for new GUID in MdeModulePkg/Include/Guid
>>>> 3) Update TerminalDxe to use this new GUID.
>>>>
>>>> I do not recommend creating a new terminal driver. Please continue as you
>>>> have which is adding support for this one new terminal type to
>>>> MdeModulePkg/Universal/Console/TerminalDxe.
>>>>
>>>> Best regards,
>>>>
>>>> Mike
>>>>
>>>>
>>> OK, I have made the above changes, and have it working with one hack
>>> I'm not sure how to properly resolve.
>>>
>>> I now have gEfiTtyTermGuid declared (extern) in
>>> MdeModulePkg/Include/Guid/TtyTerm.h, and defined in
>>> MdeModulePkg/Universal/Console/TerminalDxe/Tty.c.
>>>
>>> I use gEfiTtyTermGuid in DevicePathFromText.c in MdePkg to convert
>>> between a text path to a device path, but
>>> I don't see how to include TtyTerm.h in DevicePathFromText.c. Right
>>> now I just have added the extern to DevicePathFromText.c
>>> to verify functionality. This works, but is obviously not the right
>>> solution. How should I go about properly getting gEfiTtyTermGuid
>>> declared in DevicePathFromText.c?
>>>
>>
>> You should not define the GUID yourself, you should add it to the
>> appropriate .dec file, If you then depend on that package and guid in
>> a module's .inf, the definition will be emitted implicitly by the
>> build tools.
>
> Thanks Ard.
>
> OK, got rid of the bogus Tty.c. I already had the GUID (also)
> defined in the MdeModulePkg.dec, and the gEfiTtyTermGuid
> in the [Guid] section of the UefiDevicePathLib.inf.
> What I am missing is the declaring the dependency of UefiDevicePathLib
> on the MdeModulePackage, and I don't know how to add that.
> TerminalDxe isn't under the Library directory, and doesn't have
> a "LIBRARY_CLASS" in its .inf file, and all the examples of dependencies
> that I have found seem to rely on that.
> My somewhat vague understanding of the ED2 build system has hit its limit.
In the INF file of any module (library instance, driver module,
application, etc), you have a
[Packages]
section, under which you can list *.dec files, with pathnames relative
to the root of the edk2 clone. Once you add a dec file there, you can
reference guids, PCDs, and library classes (headers) declared in that
DEC file.
Protocol GUIDs and other GUIDs will become available for compilation by
including the appropriate include files (from under Library/, Protocol/,
and Guid/, usually); these relative include file pathnames are then
searched against all modules that you listed under [Packages].
For *linking*, you'll also have to list the protocol guids under
[Protocols] and the other guids under [Guids] in the INF file. This will
cause the build system to include *definitions* for these GUIDs in the
auto-generated C files. This way linking too will succeed.
The [LibraryClasses] section is also there for linking, but it has an
extra level of indirection. (For compilation, see Library/ above.) A
library class ultimately corresponds to a header file only, and it can
have several implementations. [LibraryClasses] therefore lists only the
sets of APIs you'd like to link against, but the actual library
implementation is resolved in the DSC file that you are building.
The DSC file can resolve a library class to a library instance
- globally, for all modules,
- for types of modules (eg. DXE_DRIVER vs. PEIM vs. UEFI_APPLICATION),
- for individual modules (identified by their INF files).
(The INF file spec describes this in much more detail, and no doubt much
more correctly; just google it.)
In addition, library instances (= implementations) can restrict
themselves to some module types. The most common example is that
libraries that write to static variables cannot be generally linked into
PEIMs, because writeable memory becomes available only at some point
during PEI; some PEIMs execute in place from flash. (There's only static
linking; dynamic linking is covered with PPIs (PEIM-to-PEIM interfaces)
and protocols.)
So a library wanting to write to a static variable would in general
restrict itself to post-PEI module types. Alternatively, its INF file
could list a dependency expression (a depex) on the
"gEfiPeiMemoryDiscoveredPpiGuid" PPI, which gets installed when DRAM
becomes available during PEI. Such a depex would be inherited by any
PEIM that linked against this particular library instance, with the
effect that the PEIM would be first dispatched only after DRAM were
initialized. (Hence allowing the library built into the module to write
to its static variables.)
Anyway, in the current case, the technical solution would be to add
MdeModulePkg/MdeModulePkg.dec under the [Packages] section in
"MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf".
However, that's no good, because MdePkg contains definitions, libraries
etc. for industry standards. For example, the DevicePathLib library
instance in question ("UefiDevicePathLib") knows about GUIDs that are
listed in the UEFI specification. So you'd either have to introduce a
cross-package dependency to MdeModulePkg (which is technically feasible,
but purity-wise it would be frowned upon I think, because MdeModulePkg
is reference implementation for a standard, not standard per se), *or*
you'd have to add gEfiTtyTermGuid to MdePkg's dec file, and the
appropriate MdePkg/Include/Guid/... header file). However, the latter
would not be accepted until gEfiTtyTermGuid were actually *standard*.
So what can you do, if neither the cross-pkg dependency nor the direct
MdePkg modification is appropriate? Two options:
- Try to standardize the GUID with the USWG. Good luck! :)
- Fork the UefiDevicePathLib library instance to some other (less
central) package, and modify it there. This sucks because any updates
to the standard location would have to be cross-ported, going forward.
The edk2 build system is actually very flexible, it's just that the
terminal stuff has always proven untouchable (to me at least). Note
though that forking a library instance (or a module for that matter) is
the *norm* for proprietary vendors, which is what edk2 (and the UEFI
spec itself) are optimized for. (Eg. the protocols are ABIs, not APIs.)
To summarize: you're facing this problem because the devpath-to-text
conversion library instance under MdePkg is tightly coupled with an
industry standard (the UEFI spec), whereas the driver modules under
MdeModulePkg are just "independent implementations" (that Intel cares
about very much though). If you want to add non-standard extensions to
the devpath-to-text conversion library, you might have to fork it (or
standardize the extension).
Sorry if I misunderstood the situation; hopefully others can correct me
then (or anyway).
Thanks
Laszlo
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
