[U-Boot] [PATCH v1] fs: fat: dynamically allocate memory for temporary buffer

[Tom Rini <trini@konsulko.com>]

On Thu, Dec 06, 2018 at 04:45:08PM +0100, Stefan Agner wrote:
> On 06.12.2018 16:13, Tom Rini wrote:
> > On Thu, Dec 06, 2018 at 02:58:52PM +0100, Stefan Agner wrote:
> > 
> >> From: Stefan Agner <stefan.agner@toradex.com>
> >>
> >> Drop the statically allocated get_contents_vfatname_block and
> >> dynamically allocate a buffer only if required. This saves
> >> 64KiB of memory.
> >>
> >> Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
> > 
> > Is there a particular issue you're running into here, or just that what
> > we're doing is just generally not a great idea?  I ask since I need to
> > poke git history to make sure that the thing at the back of my mind
> > about us needing to do this for some annoying boot case is intentional.
> 
> I was in the process checking large global variables since I had issues
> on a target with limited SRAM (used pre-relocation). I only after
> writing this patch I realized that the space for the .bss section is not
> required pre-relocation, so the patch did not help in my particular
> case.
> 
> That said, in git history I saw that get_contents_vfatname_block has
> been used more broadly in earlier FAT implementations. Now it is only
> used to handle a corner case: when loading from a file with an offset...
> I guess the .bss section is cleared, so we probably safe 64KiB of
> zeroing out... I feel it is still worth doing the change, but I don't
> have a really strong feeling.

Thanks for checking.  Yes, this is probably a good thing to do overall
and whatever historical reason we needed it like this isn't applicable
now if we're doing offset loading only in this case which isn't an SPL
thing anyhow.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181206/134eabdf/attachment.sig>