From mboxrd@z Thu Jan 1 00:00:00 1970 From: AKASHI Takahiro Date: Thu, 6 Sep 2018 11:29:31 +0900 Subject: [U-Boot] [PATCH v2 04/23] fs: fat: make directory iterator global for write use In-Reply-To: References: <20180904074948.18146-1-takahiro.akashi@linaro.org> <20180904074948.18146-5-takahiro.akashi@linaro.org> <18EEE289-75D3-4BEA-B666-B4FDBB1278DF@suse.de> <20180905021442.GD18483@linaro.org> Message-ID: <20180906022930.GG18483@linaro.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 Wed, Sep 05, 2018 at 10:16:32AM +0200, Alexander Graf wrote: > > > On 05.09.18 04:14, AKASHI Takahiro wrote: > > On Tue, Sep 04, 2018 at 12:57:54PM +0200, Alexander Graf wrote: > >> > >> > >>> Am 04.09.2018 um 12:50 schrieb Heinrich Schuchardt : > >>> > >>> > >>> > >>>> On 09/04/2018 11:01 AM, Alexander Graf wrote: > >>>> > >>>> > >>>>> On 04.09.18 09:49, AKASHI Takahiro wrote: > >>>>> Directory iterator was introduced in major re-work of read operation by > >>>>> Rob. We want to use it for write operation extensively as well. > >>>> > >>>> Please indicate in the commit message that write operations are > >>>> implemented in a different .c file and so we have to export the > >>>> respective functions. > >>> > >>> Why? Look at this ugly code: > >>> > >>> fs/fat/fat_write.c:17:#include "fat.c" > >> > >> In that case we don't need this patch at all, no? > > > > Oops, I didn't notice this before. > > If, however, "include fat.c" makes any sense, theoretically we don't need > > "depends on FS_FAT" for FS_FAT_WRITE. > > There seems to be a contradiction between the code and config. > > I'm not sure it's contradictory. Someone just implemented a poor man's > LTO by including the 2 files with each other. Well, LTO has long existed since gcc4.8 ... (and improvement would be quite small, I guess.) > > I prefer just to remove the line, '#include "fat.c"' from fat_write.c > > and add more "extern" definitions in fat.h if necessary. > > We can worry about refactoring things later down the road. By making > functions go external, we lose the compiler's ability to inline > functions which may again bloat code which may trip random boards above > size limits. > > For now, I'd suggest you leave the ugly #include "fat.c" in and not move > anything into fat.h. That way the file is self-contained and you don't > have to worry about exporting just yet. Although I won't tolerate such an ugly code, I will follow your suggestion mainly because lots of existing defconfigs enable FAT_WRITE without FS_FAT. Thanks, -Takahiro AKASHI > > Alex