Jaben, thanks. I think we're on the same page as far as the pre-Shell limitations for paths.
The downside of using this strategy is the code size overhead for UEFI drivers. BTW, we've extended the ShellLib to contain wrapper functions for nearly all Shell Protocol member functions. It makes smaller and cleaner shell applications. Tim -----Original Message----- From: Carsey, Jaben [mailto:[email protected]] Sent: Wednesday, July 06, 2016 2:12 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? 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:edk > > > 2- 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:edk > > > 2- > > > de > > > [email protected]<mailto:[email protected]>><mailto:edk2-deve > > > l@ > > > 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:edk > > > 2- 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
