Andrew,
Note: The ShellLib is not part of the shell spec. The ShellProtocol and
ShellParametersProtocol are. The current ShellLib is designed to facilitate
porting and writing of apps for the shell. The porting will become obsolete
over time as we encounter fewer and fewer EDKShell apps.
That does’t mean that your conclusion is wrong. We could make a different
ShellLib that is not actually dependent on the shell.
Michael,
You can have different libs and different flags per driver. You use the {}
syntax on the INF file in the components section. This is already done in the
Shell.DSC to control PCDs separating the ShellLib when used for the shell
compared to ShellLib used for shell applications.
-Jaben
From: Michael Zimmermann [mailto:[email protected]]
Sent: Wednesday, July 06, 2016 1:13 PM
To: Andrew Fish <[email protected]>
Cc: Marvin Häuser <[email protected]>; [email protected];
Carsey, Jaben <[email protected]>; [email protected]
Subject: Re: [edk2] StdLib usage for drivers?
Importance: High
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]<mailto:[email protected]>> wrote:
On Jul 6, 2016, at 12:44 PM, Michael Zimmermann
<[email protected]<mailto:[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]<mailto:[email protected]>> wrote:
> On Jul 4, 2016, at 11:17 AM, Marvin Häuser
> <[email protected]<mailto:[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]<mailto:[email protected]>]
> Sent: Thursday, June 23, 2016 5:32 AM
> To: Marvin Häuser
> <[email protected]<mailto:[email protected]>>
> Cc: [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[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]><mailto:[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]><mailto:[email protected]<mailto:[email protected]>>]
> Sent: Wednesday, June 22, 2016 10:28 PM
> To: Marvin H?user
> <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>
> Cc:
> [email protected]<mailto:[email protected]><mailto:[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]>><mailto:[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]>><mailto:[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]><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
