If you are writing something that is only used from the shell, the 
EfiShellProtocol also provides functions to decode the file system string 
identifiers ("fs0") and block string identifiers ("blk0").  This makes it 
easier for users to interact with your application if that is required.

-Jaben

-----Original Message-----
From: Bill Paul [mailto:wp...@windriver.com] 
Sent: Wednesday, February 26, 2014 12:20 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Locating a file in the file system

Of all the gin joints in all the towns in all the world, John Davis had to walk 
into mine at 10:30:59 on Wednesday 26 February 2014 and say:

> Hello
> 
> Is there an example someplace for accessing a file in the filesystem?  
> I would like to be able to read a file into a buffer as a simple 
> exercise. I saw the earlier notes about doing this via stdlib/posix 
> api calls.  I figure there is a similar method to do this via uefi 
> api.  Later I want to be able to locate a .fv file for use by the firmware 
> volume routines.

I would start by reading up on SimpleFileSystemProtocol. From an application, 
you can use it to access files in a supported filesystem (typically FAT32). 
You need a handle to use it. When you application is executed, you can get a 
handle for the device it was loaded from, or you can search for all handles 
that support SimpleFileSystemProtocol that the firmware currently knows about.

In the former case, you can use BS->HandleProtocol() to get an EFI_LOADED_IMAGE 
protocol handle from your image pointer (which is passed to you via UefiMain().

    EFI_LOADED_IMAGE li;
    EFI_HANDLE handle;

    gBS->HandleProtocol (image, &gEfiLoadedImageProtocolGuid, (void *)&li);
    handle = li->DeviceHandle;
    
In the latter case, you can use BS->LocateHandle with the ByProtocol flag to 
search for all handles that support SimpleFileSystemProtocol. If you do it this 
way and there's more than one handle that can be accessed via 
SimpleFileSystemProtocol, you need to make a decision to choose one.

    UINTN handleSize = 0;
    EFI_HANDLE * handles = NULL;

    gBS->LocateHandle (ByProtocol, &gEfiLoadedImageProtocolGuid, NULL,
        &handleSize, handles);

    /* Remember to free this later. */
    handles = AllocatePool (handleSize);

    gBS->LocateHandle (ByProtocol, &gEfiLoadedImageProtocolGuid, NULL,
        &handleSize, handles);

Once you have your device handle, you can start reading a file from it:

    EFI_FILE_IO_INTERFACE * vol;
    EFI_FILE_HANDLE root;
    EFI_FILE_HANDLE fp;
    EFI_FILE_INFO * info;
    UINTN s;
    UINT8 * buf;

    gBS->HandleProtocol (handle, gEfiSimpleFileSystemProtocolGuid,
       (void **)&vol);

    /* Open root directory of the volume. */
    vol->OpenVolume (vol, &root);
    root->Open (root, &fp, L"FileName", EFI_FILE_MODE_READ, 0);

    /* Get the file size. */
    s = 0;
    fp->GetInfo (fp, gEfiFileInfoGuid, &s, NULL);
    info = AllocatePool(s);
    fp->GetInfo (fp, gEfiFileInfoGuid, &s, info);
    s = (UINTN)info->filesSize;
    FreePool (info);

    /* Read the file */
    buf = AllocatePool (s);
    fp->Read (fp, &s, buf);

    fp->Close (fp);

That's my understanding anyway. There are probably various examples out there.

Note that there are a lot of service routines that expect you to provide them 
with a buffer big enough to contain the results. If you give them a buffer 
that's too small (or 0), they return EFI_BUFFER_TOO_SMALL and set the size to 
indicate how much is needed. You then allocate the required memory and call the 
functions again. That's what's happening with the LocateHandle() and
GetInfo() calls above. You should add error checking to confirm that they 
return EFI_BUFFER_TOO_SMALL rather than some other error before proceeding.

> On a related note, how do you folks find routines? I'm doing massive 
> greps though the header files trying to find routines which have a 
> similar name to what I am doing.  I'm also using google to search but 
> that is hit and miss.  For example, google "UEFI file open" gives me 
> results about opening a .efi file via explorer.  That is not what I want to 
> do.

For searching for things in the EDKII source, I cheat. I go to the github 
mirror at https://github.com/tianocore/edk2 and search the source tree from 
there (where it says "Search or type a command").

As for what things are supported, from an application standpoint, the 
definitive list of supported services is the UEFI specification itself. It 
describes all the supported boot services and runtime services. Anything not 
described in the spec is a library function provided by the EDK itself.

-Bill

--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Member of Technical Staff,
                 wp...@windriver.com | Master of Unix-Fu - Wind River Systems 
=============================================================================
   "I put a dollar in a change machine. Nothing changed." - George Carlin 
=============================================================================

------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize 
your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to