I think that I generally agree with what has been said. I really like your idea of not having 3 copies of functions floating around.
I probably fail to notice the StdLib emails as I pay attention to the shell and miss these. I will endeavor to pay more attention (and fix my email flag rules). -Jaben > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of > Daryl McDaniel > Sent: Monday, July 04, 2016 5:33 PM > To: 'Marvin Häuser' <[email protected]>; edk2- > [email protected] > Cc: Carsey, Jaben <[email protected]>; 'Michael Zimmermann' > <[email protected]> > Subject: Re: [edk2] StdLib usage for drivers? > Importance: High > > 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:[email protected]] > Sent: Monday, July 04, 2016 11:18 AM > To: [email protected] > Cc: Michael Zimmermann <[email protected]>; edk2- > [email protected]; Carsey, Jaben <[email protected]> > 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:[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]> > > 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/bf7a296718486bafaf774ea8bcf187 > c162c3c167 > > and this is how you convert a Shell project to a NonShell one: > https://github.com/efidroid/uefi_apps_EFIDroidUi/commit/23f0fa08108b8f8 > 52564fae733c6a7bce62e2070 > > 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:edk2- > [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
