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. 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
