> On Jul 6, 2016, at 1:13 PM, Michael Zimmermann <[email protected]>
> wrote:
>
> Andrew,
>
> the problem with multiple library instances is that this does only work
> globally and it gets in your way if you need different versions of a
> dependent library.
>
> In our case, Applications/Drivers only depend on LibC, an LibC then depends
> on ShellLib which means we'd have to create another LibC instance which
> depends on another version of ShellLib.
>
> In other words: you can't use the same Library with different build options
> in different drivers built by the same DSC. You'd have to create a renamed
> .inf with different build options which you can't do because your driver
> doesn't depend directly on that lib.
>
Micheal,
The library implementations, drivers, and applications only depend on a library
class. It is the DSC file that picks the instance. The DSC syntax allows you to
specify the binding per driver if required. It looks like:
ShellPkg/Application/Shell/Shell.inf {
<LibraryClasses>
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
NULL|ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.inf
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
# SafeBlockIoLib|ShellPkg/Library/SafeBlockIoLib/SafeBlockIoLib.inf
#
SafeOpenProtocolLib|ShellPkg/Library/SafeOpenProtocolLib/SafeOpenProtocolLib.inf
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
<PcdsFixedAtBuild>
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
}
Thanks,
Andrew Fish
> Thanks
> Michael
>
> On Wed, Jul 6, 2016 at 9:55 PM, Andrew Fish <[email protected]> wrote:
>
>>
>> On Jul 6, 2016, at 12:44 PM, Michael Zimmermann <[email protected]>
>> wrote:
>>
>> Andrew,
>>
>> sry for not reasing the Shell Spec but I think you can answer this faster.
>> Does the Spec prevent implementing such a 'pure-EFI' fallback by default
>> so we can use the same ShellLib globally?
>>
>>
>> Michael,
>>
>> If I remember correctly the Shell Spec specifies how the shell functions
>> and what protocols it produces that other code can depend on.
>>
>> and follow-up question: Libraries are not compiled multiple times right?
>> so If I would specify additional CFLAGs these would only be used to build
>> your package and not for the libraríes you are using right?
>>
>>
>> The edk2 has the concept of library instances. The DSC file for the
>> platform picks the instance of the library for the Module Type. Basically
>> ShellLib.h would be the public API and ShellLib is the library class. The
>> library class is the public API and it is names in the [Defines] section of
>> the libraries INF file via LIBRARY_CLASS =. The build system is smart
>> enough to only build the libraries that are actually being used.
>>
>> For example this would be the line in the DSC:
>> ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>>
>> And you could change it to:
>> ShellLib | AltPathToUefiShellLib/AltUefiShellLib.inf
>>
>> The upside to all this is the same reason we introduced the concept of
>> library classes in the 1st place, you can change the behavior of the StdLib
>> without modifying any of the code in the standard lib. This would be a good
>> way to experiment and if you get it working I guess it could get added to
>> the StdLib at some point as an alternate way to build it.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>> If that's correct then we should stay away from changing ShellLib's
>> behavior using cflags in your DSC because it would prevent building both
>> shell and efi users of ShellLib with one DSC file.
>>
>> Thanks,
>> Michael
>>
>> On Wed, Jul 6, 2016 at 9:25 PM, Andrew Fish <[email protected]> wrote:
>>
>>>
>>>> On Jul 4, 2016, at 11:17 AM, Marvin Häuser <[email protected]>
>>> wrote:
>>>>
>>>> Daryl, Jaben,
>>>>
>>>> As you are the package maintainers of StdLib, could you please comment
>>> on the situation?
>>>> If modifications to have StdLib working for drivers are welcome, I
>>> would offer my help in cleaning up the existing stuff and/or write my own
>>> patches, though of course there is little point if there is no reaction
>>> from the reviewers.
>>>> If it is of any interest, I want to write a shim library for Capstone
>>> and would prefer not to have three copies of Std functions in my tree
>>> (StdLib, CryptoPkg (SSL) and Capstone), but rather an improved StdLib that
>>> works for all.
>>>>
>>>> Thanks to those who have offered alternative solutions, but I prefer to
>>> keep it ‚clean‘ and have the libraries shipping with EDK2 work. :)
>>>>
>>>
>>> Marvin,
>>>
>>> It looks like the StdLib has a dependency on the ShellLib and
>>> ShellCEntryLib. One option would be to implement a new instance of the
>>> ShellLib and the ShellCEntryLib that don't depend on the Shell. You can get
>>> a template of how to do file operations from here:
>>> https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/Library/EfiFileLib/EfiFileLib.c
>>>
>>> You would have a couple of options. You good go with the EfiFileLib
>>> volume synatax, you could just do pure EFI (unclear how to specify a volume
>>> (driver letter)). You could also just add code to fallback if you can't
>>> find the shell protocols to due more pure EFI stuff. That way you don't
>>> need to modify the StdLib just how you build the StdLib from the DSC.
>>>
>>> For example you could implement the functions in the ShellLib that the
>>> StdLib requires and use something like the EfiFileLib to make it easier. I
>>> think ShellCEntryLib would just be a copy of
>>> https://github.com/tianocore/edk2/tree/master/MdePkg/Library/UefiApplicationEntryPoint
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>>
>>>> Regards,
>>>> Marvin.
>>>>
>>>> From: Michael Zimmermann [mailto:[email protected]]
>>>> Sent: Thursday, June 23, 2016 5:32 AM
>>>> To: Marvin Häuser <[email protected]>
>>>> Cc: [email protected]; [email protected]
>>>> Subject: Re: [edk2] StdLib usage for drivers?
>>>>
>>>> well for the patch to go upstream it would have to get improved a lot.
>>>> I've tried to implement this in a way that doesn't need a different dsc
>>> but the problem is that ShellLib's constructor ASSERT's if it can't find
>>> the shell protocol and removing that would probably be against the spec's.
>>>>
>>>> Also it appears that the StdLib maintainers are kinda busy because most
>>> of the StdLib patches I've sent to this mailing list didn't get reviewed.
>>>>
>>>> Thanks
>>>> Michael
>>>>
>>>> On Wed, Jun 22, 2016 at 10:37 PM, Marvin Häuser <
>>> [email protected]<mailto:[email protected]>> wrote:
>>>> Hey Michael,
>>>>
>>>> Thank you for your input! This looks interesting.
>>>> Maybe it would be a good idea to provide the libraries that depend on
>>> Shell (in master) with functions that call ASSERT (FALSE); for drivers? I
>>> do not need file I/O, so I think your modifications might work out well for
>>> me. Would be very nice of course if such changes found their way upstream.
>>> :)
>>>>
>>>> And thank you very much for your comment as well, Andrew! It makes
>>> sense that StdLib is primarily targeted at porting console applications to
>>> UEFI Shell.
>>>>
>>>> Regards,
>>>> Marvin.
>>>>
>>>> From: Michael Zimmermann [mailto:[email protected]<mailto:
>>> [email protected]>]
>>>> Sent: Wednesday, June 22, 2016 10:28 PM
>>>> To: Marvin H?user <[email protected]<mailto:
>>> [email protected]>>
>>>> Cc: [email protected]<mailto:[email protected]>
>>>> Subject: Re: [edk2] StdLib usage for drivers?
>>>>
>>>> In my fork of edk2 I've added support for using StdLib without the
>>> Shell.
>>>> It's quite hacky(setenv/getenv are stubs, no File IO and maybe other
>>> things hidden by linker GC and me not using all features).
>>>>
>>>> But depending on which StdLib features you need this can work pretty
>>> good.
>>>>
>>>> here's the commit that does the magic:
>>>>
>>> https://github.com/efidroid/edk2/commit/bf7a296718486bafaf774ea8bcf187c162c3c167
>>>>
>>>> and this is how you convert a Shell project to a NonShell one:
>>>>
>>> https://github.com/efidroid/uefi_apps_EFIDroidUi/commit/23f0fa08108b8f852564fae733c6a7bce62e2070
>>>>
>>>> as you can see it works by using StdLib with different libraries/cflags
>>> so you have to compile your driver separately if there are other modules
>>> which need the normal StdLib.
>>>>
>>>> Thanks
>>>> Michael
>>>>
>>>> On Wed, Jun 22, 2016 at 9:38 PM, Marvin H?user <
>>> [email protected]<mailto:[email protected]><mailto:
>>> [email protected]<mailto:[email protected]>>> wrote:
>>>> Dear EDK2 developers,
>>>>
>>>> For an experimental project, I'm currently attempting to write a
>>> library wrapper for the disassembler library 'Capstone' in a similar manner
>>> to CryptoPkg's OpensslLib. As most C libraries, it also depends on the
>>> standard headers, which are not provided by 'stock' EDK2. My first guess
>>> has been to use StdLib, though its description states:
>>>> 'Due to the execution environment built by the StdLib component,
>>> execution as a UEFI driver can cause system stability issues.'
>>>>
>>>> Inspecting OpensslLib I discovered that CryptoPkg deploys its own
>>> include files for StdLib. Though, from your experience, what are the issues
>>> with using StdLibPkg with DXE/UEFI drivers? It might be nice to reduce
>>> duplicate code, though I honestly don't know anything about StdLibPkg and
>>> its implementation and would be thankful for some insight on that manner.
>>>>
>>>> Thank you in advance for your time!
>>>>
>>>> Regards,
>>>> Marvin.
>>>> _______________________________________________
>>>> edk2-devel mailing list
>>>> [email protected]<mailto:[email protected]><mailto:
>>> [email protected]<mailto:[email protected]>>
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>>
>>>> _______________________________________________
>>>> edk2-devel mailing list
>>>> [email protected]<mailto:[email protected]>
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>>
>>>> _______________________________________________
>>>> edk2-devel mailing list
>>>> [email protected]
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>
>>>
>>
>>
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
