You are correct. Device paths always work fine. DevicePaths are what are in BootXXXX and DriverXXXX variables.
The missing piece is the conversion from FSX to the starting node. > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of > Tim Lewis > Sent: Wednesday, July 06, 2016 2:09 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 > > 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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
