Just to give you even more assurance that it's possible, I made a EFI_SIMPLE_FILE_SYSTEM_PROTOCOL/EFI_FILE_PROTOCOL wrapper for NTFS-3G that works great in every shell I've tested it on. Directory navigation was tricky to get working correctly. I ended up caching the directory list in EFI_FILE_PROTOCOL.Open() and just moving through the cached data structure in EFI_FILE_PROTOCOL.Read(). If the problem is an infinite loop, maybe look and see if you're implementing EFI_FILE_PROTOCOL.Set/GetPosition() correctly. Set/GetPosition() works differently for directories than it does for files.
Thomas Rognon On Wed, Aug 13, 2014 at 2:11 PM, Andrew Fish <af...@apple.com> wrote: > > On Aug 13, 2014, at 10:34 AM, Felipe Mesquita <felipe.mesqu...@lsbd.ufc.br> > wrote: > > Hello, > > I'm implementing an UEFI driver that, in its Start() function, installs an > EFI_FILE_SYSTEM_PROTOCOL instance in the controller handle passed as > argument. > My expectation was that, once I had a consistent implementation for this > protocol(and the underlying EFI_FILE_PROTOCOL returned by it), I'd be able > to navigate through this filesystem using the shell as already happens with > FAT volumes. > After loading the driver and executing "map -r", a new volume/alias > appears(as *fsnt0:*, since the driver doesn't install an > EFI_BLOCK_IO_PROTOCOL), but I can't perform any filesystem operations on it > through the shell(trying to "ls" in it, for example, makes it loop > infinitely through several calls to Open, Close and GetInfo). When I > investigated what might have gone wrong, I noticed some hints(in the specs > and the source code itself) that seem to indicate that the shell assumes a > FAT filesystem or, at least, the existence of an EFI_BLOCK_IO_PROTOCOL > under the same handle. > > So here is my question: in order to navigate through a volume using the > shell, is it enough to provide a new EFI_FILE_SYSTEM_PROTOCOL instance? If > not, what other assumptions are made by the shell? Are there any > differences in the assumptions made by the shell versions? > The shell version I'm using is 2.31. > > > The emulators produce EFI_FILE_SYSTEM_PROTOCOL instance on top of Win > APIs/POSIX APIs, and they don’t produce EFI_BLOCK_IO_PROTOCOL. > > https://svn.code.sf.net/p/edk2/code/trunk/edk2/Nt32Pkg/WinNtSimpleFileSystemDxe/ > > > https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmulatorPkg/EmuSimpleFileSystemDxe/ > > https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmulatorPkg/Unix/Host/PosixFileSystem.c > > It may be easier to figure out the behavior from looking at the POSIX > example. I’m guessing your code is doing something that is confusing the > upper level code. > > If the shell is depending on EFI_BLOCK_IO_PROTOCOL then that would seem > like a bug. The shell naming a volume fsntX based on no BlockIO protocol is > probably a bad implementation choice in the shell but it should not impact > functionality. > > It looks like the edk2 shell does not make a lot of use of the data > returned by the EFI_BLOCK_IO_PROTOCOL: > ~/work/src/edk2/ShellPkg(master)>git grep EFI_BLOCK_IO_PROTOCOL > Library/UefiShellDebug1CommandsLib/Dblk.c:35: *EFI_BLOCK_IO_PROTOCOL* > *BlockIo; > Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c:176: > *EFI_BLOCK_IO_PROTOCOL* *BlkIo; > Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c:346: > *EFI_BLOCK_IO_PROTOCOL* *BlkIo; > > EFI_FILE_SYSTEM_PROTOCOL is NOT FAT centric in any way. EFI_FILE_INFO, > EFI_FILE_SYSTEM_INFO, and EFI_FILE_SYSTEM_VOLUME_LABEL should abstract the > caller from any FAT data structures. Also GetInfo() InformationType is a > EFI_GUID so you can define a GUID and associate it with a data structure to > give access to extra information about your file system if needed. > > If I had to guess you probably have in an issue in the way you are > returning directories and that is just confusing everything. > > Thanks, > > Andrew Fish > > > Thanks in advance, > > -- > [image: LSBD] <http://www.lsbd.ufc.br/> > *Felipe Martins Mesquita* > > Technical Lead > > BSc in Computer Science - UFC > > GTalk: felipe.mesqu...@lsbd.ufc.br > > Skype: felipe.martins23 > > ------------------------------------------------------------------------------ > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > >
------------------------------------------------------------------------------
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
