[U-Boot] [PATCH 2/2] fs/fat: Optimizes memory size with single global variable instead of 3

[Benoît Thébaudeau]

Hi,

On Fri, Sep 9, 2016 at 6:34 PM, Brüns, Stefan
<Stefan.Bruens at rwth-aachen.de> wrote:
> On Sonntag, 14. August 2016 00:57:38 CEST Benoît Thébaudeau wrote:
>> On Tue, Aug 2, 2016 at 9:35 PM, Benoît Thébaudeau
>>
>> <benoit.thebaudeau.dev at gmail.com> wrote:
>> > On Tue, Aug 2, 2016 at 8:53 PM, Stephen Warren <swarren at wwwdotorg.org>
> wrote:
>> >> On 07/28/2016 12:11 AM, Tien Fong Chee wrote:
>> >>> Single 64KB get_contents_vfatname_block global variable would be used
>> >>> for
>> >>> all FAT implementation instead of allocating additional two global
>> >>> variables
>> >>> which are get_denfromdir_block and do_fat_read_at_block. This
>> >>> implementation
>> >>> can help in saving up 128KB memory space.
>> >>
>> >> The series,
>> >>
>> >> Tested-by: Stephen Warren <swarren at nvidia.com>
>> >> (via DFU's FAT reading/writing on various Tegra; likely primarily FAT
>> >> rather than VFAT though)
>> >>
>> >> Reviewed-by: Stephen Warren <swarren at nvidia.com>
>> >
>> > I suspect that reading a filename with VFAT entries crossing a cluster
>> > boundary in a FAT32 root directory will be broken by this series. I do
>> > not have time to test this and other corner cases right now though,
>> > but it will be possible in the next few weeks.
>>
>> I have tested VFAT long filenames with the current implementation on
>> Sandbox. It's completely broken:
>>  - There is a length limit somewhere between 111 and 120 characters,
>> instead of 256 characters. Beyond this limit, the files are invisible
>> with ls.
>
> That one is expected. U-Boot limits the extended name to 9 "slots", each 26
> bytes. As filenames are encoded as UTF-16/UCS-2, each ASCII character uses two
> bytes -> 9 * 26 / 2 = 117.

Indeed. I had only checked VFAT_MAXLEN_BYTES, not VFAT_MAXSEQ.

>>  - Some filenames are truncated or mixed up between files. I have
>> tested 111-character random filenames for 1000 empty files in the root
>> directory. Most filenames had the expected length, but a few were
>> shorter or longer.
>
> Where there any filenames with characters outside the ASCII range? There may
> have been some double en-/decoding of UTF-8 vs UTF-16.

No, only alnum for the affected files. There may have been one or two
filenames from previous tests outside the ASCII range, though, but I
don't think so.

Best regards,
Benoît