Sure, the FSx: names are created by the shell. So before the shell loads, there is no Shell protocol, so no mapping names. That means that the StdLib implementation statically linked with a UEFI driver will not find the Shell protocol and will not be able to match any volume names (FSx or consistent mapping or any user-created mappings), but the rest of the device path rules should apply. So, for example \PciRoot(0)\Pci(0,31)\Usb(0,0)\Mbr()\BootX64.efi could work, right? Those are the types of device paths that a UEFI driver might find in the BootXXXX variables and want to use.
Tim -----Original Message----- From: Carsey, Jaben [mailto:[email protected]] Sent: Wednesday, July 06, 2016 2:02 PM To: Tim Lewis <[email protected]>; [email protected] Cc: [email protected]; Michael Zimmermann <[email protected]>; Daryl McDaniel ([email protected]) <[email protected]>; Carsey, Jaben <[email protected]> Subject: RE: [edk2] StdLib usage for drivers? Tim, Good catch. I did not consider HII stuff. If you use a UEFI Shell Spec defined "consistent map name", it works without the shell since that is a 1:1 conversion with DevicePath. If you use a Shell map name, then it can try, but there is no guarantee that enumerations are right. Using FS0: based mapping in a driver is very scary to me. -Jaben > -----Original Message----- > From: Tim Lewis [mailto:[email protected]] > Sent: Wednesday, July 06, 2016 1:58 PM > To: Carsey, Jaben <[email protected]>; [email protected] > Cc: [email protected]; Michael Zimmermann > <[email protected]>; Daryl McDaniel > ([email protected]) <[email protected]> > Subject: RE: [edk2] StdLib usage for drivers? > Importance: High > > Jaben -- > > I can certainly recall instances where drivers that publish HII setup > pages load things from the disk (such as when checking for specific file > names). > > I also seem to recall that the original EDK shell library was designed > to that volume names were simply ignored if the shell protocol was not > present. This is essentially what the Shell APIs do, right? They just > convert mapping names into device path snippets. > > Tim > > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of > Carsey, Jaben > Sent: Wednesday, July 06, 2016 1:53 PM > To: [email protected] > Cc: Carsey, Jaben <[email protected]>; [email protected]; > Michael Zimmermann <[email protected]>; Daryl McDaniel (edk2- > [email protected]) <[email protected]> > Subject: Re: [edk2] StdLib usage for drivers? > > The thing that I am trying to figure out is what LibC APIs is really > needed by the driver? > > UEFI Drivers are not supposed to do things like FILE I/O, so who cares > if they would fail if they were called… > > Sidenote: I think that daShell.c is only used when you ask LibC for > things that come from the shell… > > This snippet makes standard APIs point to shell specific ones… > LibC/Uefi/Devices/UefiShell/daShell.c:814: Stream->Abstraction.fo_close = > &da_ShellClose; > LibC/Uefi/Devices/UefiShell/daShell.c:815: Stream->Abstraction.fo_read = > &da_ShellRead; > LibC/Uefi/Devices/UefiShell/daShell.c:816: Stream->Abstraction.fo_write = > &da_ShellWrite; > LibC/Uefi/Devices/UefiShell/daShell.c:818: Stream->Abstraction.fo_poll = > &da_ShellPoll; > LibC/Uefi/Devices/UefiShell/daShell.c:820: Stream->Abstraction.fo_stat = > &da_ShellStat; > LibC/Uefi/Devices/UefiShell/daShell.c:821: Stream->Abstraction.fo_ioctl = > &da_ShellIoctl; > LibC/Uefi/Devices/UefiShell/daShell.c:822: > Stream->Abstraction.fo_delete = &da_ShellDelete; > LibC/Uefi/Devices/UefiShell/daShell.c:823: > Stream->Abstraction.fo_rmdir = &da_ShellRmdir; > LibC/Uefi/Devices/UefiShell/daShell.c:824: > Stream->Abstraction.fo_mkdir = &da_ShellMkdir; > LibC/Uefi/Devices/UefiShell/daShell.c:825: > Stream->Abstraction.fo_rename = &da_ShellRename; > LibC/Uefi/Devices/UefiShell/daShell.c:826: Stream->Abstraction.fo_lseek = > &da_ShellSeek; > > > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, July 06, 2016 1:48 PM > To: Carsey, Jaben <[email protected]> > Cc: Michael Zimmermann <[email protected]>; Marvin Häuser > <[email protected]>; [email protected]; edk2- > [email protected] > Subject: Re: [edk2] StdLib usage for drivers? > Importance: High > > > On Jul 6, 2016, at 1:39 PM, Carsey, Jaben > <[email protected]<mailto:[email protected]>> wrote: > > It works for libs. If you specify a specific LibraryClass > implementation, it will not add a second of that library class. > > Side note: what if you turn off AutoInitialize PCD for the shell lib? > That would get rid of your main issue (the constructor ASSERT)… then > we can see what other issues you have. > > > This seems like the set of library APIs that would be needed (and one > usage of gEfiShellProtocol->SetCurDir()). > > ~/work/src/edk2/StdLib(master)>git grep Shell -- *.c > LibC/Main/Main.c:20:#include <Library/ShellCEntryLib.h> > LibC/Main/Main.c:130:ShellAppMain ( LibC/StdLib/Environs.c:23:#include > <Library/ShellLib.h> > LibC/StdLib/Environs.c:155: OpStat = ShellExecute( &MyHandle, gMD- > >UString, FALSE, NULL, &CmdStat); > LibC/StdLib/Environs.c:167: are determined by the underlying UEFI Shell > implementation. > LibC/StdLib/Environs.c:181: EfiEnv = ShellGetEnvironmentVariable(gMD- > >UString); > LibC/StdLib/Environs.c:248: HostName = ShellGetEnvironmentVariable ( > UName ); > LibC/StdLib/Environs.c:254: Status = ShellSetEnvironmentVariable ( > UName, UValue, TRUE ); > LibC/StdLib/Environs.c:265: Status = ShellSetEnvironmentVariable ( > UName, UValue, FALSE ); > LibC/Uefi/Devices/UefiShell/daShell.c:2: Abstract device driver for > the UEFI Shell-hosted environment. > LibC/Uefi/Devices/UefiShell/daShell.c:4: In a Shell-hosted > environment, this is the driver that is called > LibC/Uefi/Devices/UefiShell/daShell.c:21:#include > <Library/ShellLib.h> > LibC/Uefi/Devices/UefiShell/daShell.c:40:/** EFI Shell specific > operations for close(). > LibC/Uefi/Devices/UefiShell/daShell.c:50:da_ShellClose( > LibC/Uefi/Devices/UefiShell/daShell.c:54: EFIerrno = ShellCloseFile( > (SHELL_FILE_HANDLE *)&Fp->devdata); > LibC/Uefi/Devices/UefiShell/daShell.c:61:/** EFI Shell specific > operations for deleting a file or directory. > LibC/Uefi/Devices/UefiShell/daShell.c:71:da_ShellDelete( > LibC/Uefi/Devices/UefiShell/daShell.c:77: Status = ShellDeleteFile( > (SHELL_FILE_HANDLE *)&filp->devdata); > LibC/Uefi/Devices/UefiShell/daShell.c:86:/** EFI Shell specific > operations for setting the position within a file. > LibC/Uefi/Devices/UefiShell/daShell.c:97:da_ShellSeek( > LibC/Uefi/Devices/UefiShell/daShell.c:113: Status = ShellSetFilePosition( > FileHandle, 0xFFFFFFFFFFFFFFFFULL); > LibC/Uefi/Devices/UefiShell/daShell.c:117: Status = ShellGetFilePosition( > FileHandle, (UINT64 *)&CurPos); > LibC/Uefi/Devices/UefiShell/daShell.c:128: Status = ShellSetFilePosition( > FileHandle, (UINT64)(CurPos + offset)); > LibC/Uefi/Devices/UefiShell/daShell.c:131: Status = ShellGetFilePosition( > FileHandle, (UINT64 *)&CurPos); > LibC/Uefi/Devices/UefiShell/daShell.c:161:da_ShellMkdir( > LibC/Uefi/Devices/UefiShell/daShell.c:177: Status = ShellCreateDirectory( > NewPath, &FileHandle); > LibC/Uefi/Devices/UefiShell/daShell.c:179: FileInfo = ShellGetFileInfo( > FileHandle); > LibC/Uefi/Devices/UefiShell/daShell.c:180: Status = RETURN_ABORTED; // > In case ShellGetFileInfo() failed > LibC/Uefi/Devices/UefiShell/daShell.c:184: Status = ShellSetFileInfo( > FileHandle, FileInfo); > LibC/Uefi/Devices/UefiShell/daShell.c:187: > (void)ShellCloseFile(&FileHandle); > LibC/Uefi/Devices/UefiShell/daShell.c:199:/** EFI Shell specific > operations for reading from a file. > LibC/Uefi/Devices/UefiShell/daShell.c:212:da_ShellRead( > LibC/Uefi/Devices/UefiShell/daShell.c:224: BufSize = > (ssize_t)da_ShellSeek(filp, *offset, SEEK_SET); > LibC/Uefi/Devices/UefiShell/daShell.c:233: Status = ShellReadFile( > FileHandle, (UINTN *)&BufSize, Buffer); > LibC/Uefi/Devices/UefiShell/daShell.c:250:/** EFI Shell specific > operations for writing to a file. > LibC/Uefi/Devices/UefiShell/daShell.c:263:da_ShellWrite( > LibC/Uefi/Devices/UefiShell/daShell.c:286: BufSize = > (ssize_t)da_ShellSeek(filp, Position, How); > LibC/Uefi/Devices/UefiShell/daShell.c:295: Status = ShellWriteFile( > FileHandle, (UINTN *)&BufSize, (void *)Buffer); > LibC/Uefi/Devices/UefiShell/daShell.c:312:/** EFI Shell specific > operations for getting information about an open file. > LibC/Uefi/Devices/UefiShell/daShell.c:324:da_ShellStat( > LibC/Uefi/Devices/UefiShell/daShell.c:338: FileInfo = > ShellGetFileInfo( FileHandle); > LibC/Uefi/Devices/UefiShell/daShell.c:374:/** EFI Shell specific > operations for low-level control of a file or device. > LibC/Uefi/Devices/UefiShell/daShell.c:386:da_ShellIoctl( > LibC/Uefi/Devices/UefiShell/daShell.c:399: FileInfo = > ShellGetFileInfo( FileHandle); > LibC/Uefi/Devices/UefiShell/daShell.c:427: Status = > ShellSetFileInfo(FileHandle, FileInfo); > LibC/Uefi/Devices/UefiShell/daShell.c:446:/** EFI Shell specific > operations for opening a file or directory. > LibC/Uefi/Devices/UefiShell/daShell.c:459:da_ShellOpen( > LibC/Uefi/Devices/UefiShell/daShell.c:462: int DevInstance, > /* Not > used by Shell */ > LibC/Uefi/Devices/UefiShell/daShell.c:511: !!!!!!!!! Change this to > use > ShellSetFileInfo() to actually truncate the file > LibC/Uefi/Devices/UefiShell/daShell.c:516: Status = ShellIsFile( WPath ); > LibC/Uefi/Devices/UefiShell/daShell.c:544: // Call the EFI Shell's > Open function > LibC/Uefi/Devices/UefiShell/daShell.c:545: Status = ShellOpenFileByName( > WPath, &FileHandle, OpenMode, Attributes); > LibC/Uefi/Devices/UefiShell/daShell.c:592:da_ShellPoll( > LibC/Uefi/Devices/UefiShell/daShell.c:622:/** EFI Shell specific > operations for renaming a file. > LibC/Uefi/Devices/UefiShell/daShell.c:633:da_ShellRename( > LibC/Uefi/Devices/UefiShell/daShell.c:653: OldFileInfo = > ShellGetFileInfo( > FileHandle); > LibC/Uefi/Devices/UefiShell/daShell.c:668: Status = > ShellSetFileInfo(FileHandle, NewFileInfo); > LibC/Uefi/Devices/UefiShell/daShell.c:695:/** EFI Shell specific > operations for deleting directories. > LibC/Uefi/Devices/UefiShell/daShell.c:705:da_ShellRmdir( > LibC/Uefi/Devices/UefiShell/daShell.c:721: FileInfo = > ShellGetFileInfo(FileHandle); > LibC/Uefi/Devices/UefiShell/daShell.c:727: FreePool(FileInfo); // Free > up > the buffer from ShellGetFileInfo() > LibC/Uefi/Devices/UefiShell/daShell.c:729: Status = ShellFindFirstFile( > FileHandle, &FileInfo); > LibC/Uefi/Devices/UefiShell/daShell.c:733: Status = > ShellFindNextFile( > FileHandle, FileInfo, &NoFile); > LibC/Uefi/Devices/UefiShell/daShell.c:744: /* Count == 99 and > FileInfo is > allocated if ShellFindNextFile failed. > LibC/Uefi/Devices/UefiShell/daShell.c:745: ShellFindNextFile has > freed > FileInfo itself if it sets NoFile TRUE. > LibC/Uefi/Devices/UefiShell/daShell.c:748: free(FileInfo); // Free > buffer > from ShellFindFirstFile() > LibC/Uefi/Devices/UefiShell/daShell.c:752: Status = ShellDeleteFile( > &FileHandle); > LibC/Uefi/Devices/UefiShell/daShell.c:775: ShellCloseFile( > &FileHandle); > LibC/Uefi/Devices/UefiShell/daShell.c:783:/** Construct an instance of > the abstract Shell device. > LibC/Uefi/Devices/UefiShell/daShell.c:797:__ctor_DevShell( > LibC/Uefi/Devices/UefiShell/daShell.c:814: Stream->Abstraction.fo_close = > &da_ShellClose; > LibC/Uefi/Devices/UefiShell/daShell.c:815: Stream->Abstraction.fo_read = > &da_ShellRead; > LibC/Uefi/Devices/UefiShell/daShell.c:816: Stream->Abstraction.fo_write = > &da_ShellWrite; > LibC/Uefi/Devices/UefiShell/daShell.c:818: Stream->Abstraction.fo_poll = > &da_ShellPoll; > LibC/Uefi/Devices/UefiShell/daShell.c:820: Stream->Abstraction.fo_stat = > &da_ShellStat; > LibC/Uefi/Devices/UefiShell/daShell.c:821: Stream->Abstraction.fo_ioctl = > &da_ShellIoctl; > LibC/Uefi/Devices/UefiShell/daShell.c:822: > Stream->Abstraction.fo_delete = &da_ShellDelete; > LibC/Uefi/Devices/UefiShell/daShell.c:823: > Stream->Abstraction.fo_rmdir = &da_ShellRmdir; > LibC/Uefi/Devices/UefiShell/daShell.c:824: > Stream->Abstraction.fo_mkdir = &da_ShellMkdir; > LibC/Uefi/Devices/UefiShell/daShell.c:825: > Stream->Abstraction.fo_rename = &da_ShellRename; > LibC/Uefi/Devices/UefiShell/daShell.c:826: Stream->Abstraction.fo_lseek = > &da_ShellSeek; > LibC/Uefi/Devices/UefiShell/daShell.c:828: Node = __DevRegister(NULL, > NULL, &da_ShellOpen, Stream, 1, sizeof(GenericInstance), O_RDWR); > LibC/Uefi/Devices/UefiShell/daShell.c:835:/** Destructor for > previously constructed EFI Shell device instances. > LibC/Uefi/Devices/UefiShell/daShell.c:844:__dtor_DevShell( > LibC/Uefi/SysCalls.c:20:#include <Library/ShellLib.h> > LibC/Uefi/SysCalls.c:605: The EFI ShellOpenFileByName() function is used to > perform the low-level > LibC/Uefi/SysCalls.c:618: The only valid flag combinations for > ShellOpenFileByName() are: > LibC/Uefi/SysCalls.c:990: The fstat() function is implemented using the > ShellGetFileInfo() > LibC/Uefi/SysCalls.c:1314: Cwd = ShellGetCurrentDir(NULL); > LibC/Uefi/SysCalls.c:1338: - EPERM: Operation not supported > with > this Shell version. > LibC/Uefi/SysCalls.c:1351: /* Old Shell does not support Set Current > Dir. */ > LibC/Uefi/SysCalls.c:1352: if(gEfiShellProtocol != NULL) { > LibC/Uefi/SysCalls.c:1353: Cwd = ShellGetCurrentDir(NULL); > LibC/Uefi/SysCalls.c:1362: Status = gEfiShellProtocol->SetCurDir(NULL, > UnicodePath); > PosixLib/GetPass/GetPass.c:14:#include <Library/ShellLib.h> > PosixLib/GetPass/GetPass.c:30: ReturnString = > ShellFileHandleReturnLine (gEfiShellParametersProtocol->StdIn, > &Ascii); > > Thanks, > > Andrew Fish > > > > From: Michael Zimmermann [mailto:[email protected]] > Sent: Wednesday, July 06, 2016 1:32 PM > To: Carsey, Jaben > <[email protected]<mailto:[email protected]>> > Cc: Andrew Fish <[email protected]<mailto:[email protected]>>; Marvin > Häuser > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; edk2- > [email protected]<mailto:[email protected]> > Subject: Re: [edk2] StdLib usage for drivers? > Importance: High > > > 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. > > Thanks for clearing that up. Looks like I totally misunderstood how > the {} syntax works. > Does this only work for Applications/Drivers or for Libraries too so > you don't have to do this for every driver? > > I prefer fixing the behavior at build time over implementing a > fallback because it would be weird if the application behaves totally > different depending on if you start it via the BDS or from the Shell. > > Thanks > Michael > > On Wed, Jul 6, 2016 at 10:20 PM, Carsey, Jaben > <[email protected]<mailto:[email protected]>> wrote: > 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]<mailto:[email protected]>] > Sent: Wednesday, July 06, 2016 1:13 PM > To: Andrew Fish <[email protected]<mailto:[email protected]>> > Cc: Marvin Häuser > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; Carsey, Jaben > <[email protected]<mailto:[email protected]>>; edk2- > [email protected]<mailto:[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/Librar > y/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 > ofhttps://github.com/tianocore/edk2/tree/master/MdePkg/Library/UefiAp > plicationEntryPoint > > 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]><ma > ilto:[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]><ma > il > > to:[email protected]<mailto:[email protected]>>] > > Sent: Wednesday, June 22, 2016 10:28 PM > > To: Marvin H?user > > > <[email protected]<mailto:[email protected]><ma > ilto: > > [email protected]<mailto:[email protected]>>> > > Cc: > > [email protected]<mailto:[email protected]><mailto:edk2- > > de [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/23f0fa08108b8f > > 852564fae733c6a7bce62e2070 > > > > 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]><ma > ilto:[email protected]<mailto:[email protected]>> > <mailto:[email protected]<mailto:[email protected] > m><mailto:[email protected]<mailto:Marvin.Haeuser@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 > > [email protected]<mailto:[email protected]><mailto:edk2- > > de > > [email protected]<mailto:[email protected]>><mailto:edk2-devel@ > > li > > sts.01.org<mailto:[email protected]><mailto:[email protected]. > > org<mailto:[email protected]>>> > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > _______________________________________________ > > edk2-devel mailing list > > [email protected]<mailto:[email protected]><mailto:edk2- > > de [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
