Marvin,
Personally, I would be happy for any contributions you could make for StdLib. The only remaining Shell dependencies should be: * File system support. * One or two functions in PosixLib The next big area is breaking up the MainData structure and moving its members into the sub-libraries that they are relevant to. Once that is done, I had planned on trying to break as many of the library’s interdependencies as possible. As long as StdLib continues to pass the ISO C95 compliance tests, and gets smaller instead of larger, just about anything is fair game. I had pretty much decided to abandon using the FreeBSD / NetBSD code since it is not the best suited for the EDK II environment. As Michael surmised, I’ve been traveling a lot and too busy lately to devote as much attention to StdLib as I wish I could. Please remember for your contributions; compatibility with both GCC and Microsoft compilers and both IA32 and X64 is required. If you can also retain or provide support for ARM then that would be great. I can’t speak for Jaben, so I will have to wait for his response to determine his stance on the issue. I’m willing to answer any questions about AppPkg or StdLib that I can. Thank you for your offer. Daryl McDaniel From: Marvin Häuser [mailto:marvin.haeu...@outlook.com] Sent: Monday, July 04, 2016 11:18 AM To: edk2-devel@lists.01.org Cc: Michael Zimmermann <sigmaepsilo...@gmail.com>; edk2-li...@mc2research.org; Carsey, Jaben <jaben.car...@intel.com> Subject: RE: [edk2] StdLib usage for drivers? 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. :) Regards, Marvin. From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com] Sent: Thursday, June 23, 2016 5:32 AM To: Marvin Häuser <marvin.haeu...@outlook.com <mailto:marvin.haeu...@outlook.com> > Cc: edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> ; af...@apple.com <mailto:af...@apple.com> 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 <marvin.haeu...@outlook.com <mailto:marvin.haeu...@outlook.com> > 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:sigmaepsilo...@gmail.com <mailto:sigmaepsilo...@gmail.com> ] Sent: Wednesday, June 22, 2016 10:28 PM To: Marvin H?user <marvin.haeu...@outlook.com <mailto:marvin.haeu...@outlook.com> > Cc: edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> 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 <marvin.haeu...@outlook.com <mailto:marvin.haeu...@outlook.com> <mailto:marvin.haeu...@outlook.com <mailto:marvin.haeu...@outlook.com> >> 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 edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> <mailto:edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
