[U-Boot] [PATCH v3 10/26] fs: fat: support write with non-zero offset

[Alexander Graf <agraf@suse.de>]

On 12.09.18 04:14, Akashi, Takahiro wrote:
> On Tue, Sep 11, 2018 at 01:09:43PM +0200, Alexander Graf wrote:
>>
>>
>> On 11.09.18 08:59, Akashi, Takahiro wrote:
>>> From: AKASHI Takahiro <takahiro.akashi@linaro.org>
>>>
>>> In this patch, all the necessary code for allowing for a file offset
>>> at write is implemented. What plays a major roll here is get_set_cluster(),
>>> which, in contrast to its counterpart, set_cluster(), only operates on
>>> already-allocated clusters, overwriting with data.
>>>
>>> So, with a file offset specified, set_contents() seeks and writes data
>>> with set_get_cluster() until the end of a file, and, once it reaches
>>> there, continues writing with set_cluster() for the rest.
>>>
>>> Please note that a file will be trimmed as a result of write operation if
>>> write ends before reaching file's end. This is an intended behavior
>>> in order to maintain compatibility with the current interface.
>>>
>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
>>> ---
>>>  fs/fat/fat_write.c | 288 ++++++++++++++++++++++++++++++++++++++++++---
>>>  1 file changed, 273 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
>>> index c22d8c7a46a1..651c7866debc 100644
>>> --- a/fs/fat/fat_write.c
>>> +++ b/fs/fat/fat_write.c
>>> @@ -450,6 +450,121 @@ set_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
>>>  	return 0;
>>>  }
>>>  
>>> +static __u8 tmpbuf_cluster[MAX_CLUSTSIZE] __aligned(ARCH_DMA_MINALIGN);
>>
>> I'm not sure all systems that allow FAT writing will like the additional
>> overhead this will incur.
> 
> Which part are you seeing as "overhead"?
> I know it's ugly but the same technique is also used in fat.c :)

Yeah, it just grows .bss by the cluster size. But I didn't run into any
board yet that complained, so I guess we're good.

> 
>> Have you thrown your patch set into buildman
>> to check all boards successfully build?
> 
> No, not at all.

You turned out lucky then :). If you don't want to run travis (which
basically just calls buildman), you can run buildman locally as well to
verify that the code still builds fine on all targets after your changes.


Alex