On 7/9/21 4:44 AM, AKASHI Takahiro wrote:
On Tue, Jul 06, 2021 at 05:05:19PM -0600, Simon Glass wrote:
Hi,
At present U-Boot avoids the concept of 'opening' a file. Being in a
bootloader environment, it is normally better to take the action
immediately and avoid any caching, for example, since there is no
background task to clean up afterwards.
Having said that, the concept of a file is quite useful, for example
to write the output of a command to a file, or to open a file and read
it a line at a time.
Another case has come to light in that EFI wants to access files using
a file handle. This currently uses parallel data structures and does
not map very well in U-Boot.
Not having a file descriptor slows down file operation because for each
individual access to a file we
* read the partition table
* look up the file in the directory structure
If you only use the 'load' command, this does not matter because there
is only a single read. But in the UEFI sub-system we use multiple API calls:
* open the volume
* open the file
* read the file size (for buffer allocation)
* read the file
The file descriptors in the UEFI sub-system only hold device, partition
ID, file path.
Finally, partitions has a similar issue, where defining them as a
device can have benefits, e.g. to specify the device to use directly,
rather than with the 'type dev:part' approach, perhaps providing them
in the devicetree, etc.
For the above reasons, I propose that we implement, as an option,
support for files and partitions within driver model.
With partitions as devices we will have to read the partition table only
once when the block device is probed. - For the UEFI sub-system we need
all block devices to be probed before calling the UEFI binary (e.g. GRUB).
+1
# Nobody has commented yet :)
Regarding a "file (or file descriptor)", we have already implemented
the same concept in efi_loader. So technically, it won't be a hard-work.
Regarding "partitions as udevice," I have posted an experimental
patch [1]. So it must also be feasible.
Our UEFI file descriptor is not helpful because it does not buffer the
relevant data to speed up file access. E.g. for the FAT driver a file
descriptor could buffer some information from the directory entry (file
attributes, dates) and some from the FAT table (assigned extends).
One of my concerns is what benefit end users may enjoy.
Improved performance.
Best regards
Heinrich
-Takahiro Akashi
[1] https://lists.denx.de/pipermail/u-boot/2019-February/357937.html
https://lists.denx.de/pipermail/u-boot/2019-February/357934.html
Regards,
Simon
