On Sat, Apr 16, 2022 at 08:54:48AM +0800, Qu Wenruo wrote: > Hi U-boot fs guys, > > With my previous rework on U-boot btrfs, and my own btrfs-fuse project, > it turns out that, although U-boot implements its fs with a very fuse > like interface, there are still some quality-of-life features missing. > > One of the most obvious one is making each fs to handle unaligned read. > > This is especially obvious when comparing btrfs-fuse btrfs_file_read() > against U-boot btrfs_file_read(). > > They share almost the same main loop, but btrfs_file_read() in U-boot > have two extra handling, for unaligned leading sector and unaligned > tailing sector. > > > So I just did a quick check on the other fses, it turns out that we have > a very different behaviors: > > - FAT > - Ext4 > Have the handling for both tailing and ending block. > > - Btrfs > My code, doing unaligned leading/tailing block manually. > (the tailing part looks unnecessary though) > > - Ubifs > Explicitly reject read with non-aligned offset. > > - Squshfs > Explicitly reject read with non-zero offset. > > - Erofs > Have the handling for tailing unaligned part, but doesn't seem to > handle unaligned start part. > > Thus if we have a proper common routine for unaligned read routine (get > the file length, read the first and the last unaligned block, then let > the .read callback to handle the aligned range), then all fs drivers > would have a much better life. > > Mind me to do such small but quality-of-life improve for all involved fses? > (This will need a new call back to query the blocksize of each fs though)
If it seems like something that would generally improve fs support, and I think that's what you're saying here, yes, please. Thanks. -- Tom
signature.asc
Description: PGP signature