From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 18 Aug 2015 22:01:35 -0600 Subject: [U-Boot] [PATCH V2 06/10] fat: ffconf.h changes for U-Boot port In-Reply-To: <20150815130711.GY25532@bill-the-cat> References: <1439304945-7968-1-git-send-email-swarren@wwwdotorg.org> <1439304945-7968-7-git-send-email-swarren@wwwdotorg.org> <20150814184744.GG25532@bill-the-cat> <55CEB4C0.4000200@wwwdotorg.org> <20150815130711.GY25532@bill-the-cat> Message-ID: <55D3FF9F.2090801@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 08/15/2015 07:07 AM, Tom Rini wrote: > On Fri, Aug 14, 2015 at 09:40:48PM -0600, Stephen Warren wrote: >> On 08/14/2015 12:47 PM, Tom Rini wrote: >>> On Tue, Aug 11, 2015 at 08:55:41AM -0600, Stephen Warren >>> wrote: >>>> Turn on _FS_NORTC: This means we don't have to implement >>>> get_fattime() which simplifies life for now. >>>> >>>> Automatically set _FS_READONLY based on CONFIG_FAT_WRITE. >>>> This requires including since we reference >>>> CONFIG_*. >>>> >>>> Set _USE_LFN to enable long filename handling; an essential >>>> feature. >>>> >>>> Set _FS_RPATH so that paths components "." and ".." are >>>> correctly parsed and handled. This enables paths such as >>>> "/extlinux/../foo" to work. >>>> >>>> Set _USE_LABEL so that volume labels can be read. >>> >>> Hmm, is there some way to wrap volume label support in >>> Kconfig? I'm sure this is useful in some cases, but maybe >>> something that boards that are already on the cusp of their >>> size limit would want off? >> >> It's certainly possible; ffconf.h's definition of _FS_READONLY >> is already driven by CONFIG_FAT_WRITE in this series. >> >> I'm not sure if it's worth it though; on the RPi, turning off >> volume label support only saves ~0.5K of .text, 0 .data, and 8 >> bytes .bss. If so, I can certainly throw in another patch to >> allow it to be configured. > > Yeah, OK, that's not a big enough savings to bother with I think. > On the boards where we're seeing a bigger size growth can you > investigate a little? Thanks! I haven't built a lot of boards, but I think that large size increase may have been limited to sandbox. For some reason, its config.mk doesn't contain: PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden If I add that to arch/sandbox/config.mk, then I see a much smaller size increase when switching to the new FAT implementation. There are obviously a few functions that aren't used in ff.c, but aren't ifdef'd out.