* RFC: Devices for files and partitions @ 2021-07-06 23:05 Simon Glass 2021-07-09 2:44 ` AKASHI Takahiro 0 siblings, 1 reply; 4+ messages in thread From: Simon Glass @ 2021-07-06 23:05 UTC (permalink / raw) To: U-Boot Mailing List Cc: Tom Rini, Heinrich Schuchardt, Ilias Apalodimas, Marek Vasut, Sean Anderson, Marek Behún 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. 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. Regards, Simon ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: Devices for files and partitions 2021-07-06 23:05 RFC: Devices for files and partitions Simon Glass @ 2021-07-09 2:44 ` AKASHI Takahiro 2021-07-09 5:27 ` Heinrich Schuchardt 0 siblings, 1 reply; 4+ messages in thread From: AKASHI Takahiro @ 2021-07-09 2:44 UTC (permalink / raw) To: Simon Glass Cc: U-Boot Mailing List, Tom Rini, Heinrich Schuchardt, Ilias Apalodimas, Marek Vasut, Sean Anderson, Marek Beh??n 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. > > 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. +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. One of my concerns is what benefit end users may enjoy. -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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: Devices for files and partitions 2021-07-09 2:44 ` AKASHI Takahiro @ 2021-07-09 5:27 ` Heinrich Schuchardt 2021-07-11 0:01 ` Simon Glass 0 siblings, 1 reply; 4+ messages in thread From: Heinrich Schuchardt @ 2021-07-09 5:27 UTC (permalink / raw) To: AKASHI Takahiro, Simon Glass, U-Boot Mailing List, Tom Rini, Ilias Apalodimas, Marek Vasut, Sean Anderson, Marek Beh??n 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: Devices for files and partitions 2021-07-09 5:27 ` Heinrich Schuchardt @ 2021-07-11 0:01 ` Simon Glass 0 siblings, 0 replies; 4+ messages in thread From: Simon Glass @ 2021-07-11 0:01 UTC (permalink / raw) To: Heinrich Schuchardt Cc: AKASHI Takahiro, U-Boot Mailing List, Tom Rini, Ilias Apalodimas, Marek Vasut, Sean Anderson, Marek Beh??n Hi, On Thu, 8 Jul 2021 at 23:33, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > 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. Arguably that is a potential benefit, dependent on us implementing (write-through?) caching of this info. > > >> > >> 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). It would be better if UEFI could support lazy probing, but that's off-topic here. > > > > > +1 > > > > # Nobody has commented yet :) Thank you for commenting. > > > > 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. With a bit of effort, yes, with UEFI at least, by the sound of it. I'm not sure how much difference it would make for non-EFI use though. To me this is an internal thing, a bit like driver model, where the benefit is easier development and scripting, which might benefit end users indirectly through faster time-to-market and fewer bugs? Takahiro, since you have already started this work, do you want to continue it? I think the original patch needed a test. > > 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 Regards, Simon > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-07-11 0:02 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-06 23:05 RFC: Devices for files and partitions Simon Glass 2021-07-09 2:44 ` AKASHI Takahiro 2021-07-09 5:27 ` Heinrich Schuchardt 2021-07-11 0:01 ` Simon Glass
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.