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]> 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]] > Sent: Wednesday, June 22, 2016 10:28 PM > To: Marvin H?user <[email protected]> > Cc: [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]>> 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]> > 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
