From: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH 2/2] fs: add partition switch libary, implement ls and fsload commands
Date: Thu, 11 Oct 2012 19:45:09 +0200 (CEST) [thread overview]
Message-ID: <498910150.6648038.1349977509948.JavaMail.root@advansee.com> (raw)
In-Reply-To: <5076FC61.9070807@ti.com>
On Thursday, October 11, 2012 7:05:37 PM, Tom Rini wrote:
> On 10/11/12 09:57, Stephen Warren wrote:
> > On 10/11/2012 10:47 AM, Tom Rini wrote:
> >> On 10/10/12 17:05, Stephen Warren wrote:
> >>> From: Stephen Warren <swarren@nvidia.com>
> >>
> >>> Implement "ls" and "fsload" commands that act like
> >>> {fat,ext2}{ls,load}, and transparently handle either
> >>> file-system. This scheme could easily be extended to other
> >>> filesystem types; I only didn't do it for zfs because I don't
> >>> have any filesystems of that type.
> >>
> >>> Signed-off-by: Stephen Warren <swarren@nvidia.com> --- There
> >>> are a couple FIXMEs in here:
> >>
> >>> 1) In fs/fs.c, code is ifdef on CONFIG_CMD_FAT or
> >>> CONFIG_CMD_EXT2. This means that the new commands and code can
> >>> only be enabled if the "legacy" {fat,ext2}{ls,load} are
> >>> enabled. What we really want is CONFIG_FS_FAT and
> >>> CONFIG_FS_EXT2 to enable the filesystem code, and then
> >>> CONFIG_CMD_FAT, CONFIG_CMD_EXT2, CONFIG_CMD_FS to only affect
> >>> the command implementations. However, that would require
> >>> making every include/config/*.h that sets the current defines
> >>> also set more. I suppose that's a fairly mechanical change
> >>> though, so easy enough to implement. Does that seem like a
> >>> reasonable approach to people?
> >>
> >> How about a new CONFIG_CMD_GENERIC_FS for the new ls/fsload (and
> >> any later commands like write that get added) and once most
> >> filesystems are converted we can think about a transition plan?
> >
> > Certainly.
> >
> > The issue is that the filesystem code itself is conditionally
> > included based on CONFIG_CMD_FAT and CONFIG_CMD_EXT4. This would
> > require that in order to use the new generic commands, you also
> > had to support the old non-generic commands in order to get a
> > linkable result. Perhaps that's fine for now, but by separating the
> > existing CONFIG_CMD_FAT into two (CONFIG_CMD_FAT, CONFIG_FS_FAT),
> > we could avoid that requirement. As Benoit mentioned, perhaps we
> > could arrange that CONFIG_CMD_FAT selects CONFIG_FS_FAT somehow,
> > although I haven't looked at U-Boot's configuration system to see
> > if that's possible yet.
>
> Since we don't have Kconfig right now, it's not really easy to do
> that
> kind of thing. I think once we have more filesystems converted we
> can
> work out doing the mechanical separate of fs/ from common/ for fs
> code.
This does not require Kconfig. include/config_fallbacks.h is already made for
automatic config fixups. The following lines could simply be added to it:
#if defined(CONFIG_CMD_FAT) && !defined(CONFIG_FS_FAT)
#define CONFIG_FS_FAT
#endif
Best regards,
Beno?t
next prev parent reply other threads:[~2012-10-11 17:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-11 0:05 [U-Boot] [RFC PATCH 1/2] fs: delete unused Makefile Stephen Warren
2012-10-11 0:05 ` [U-Boot] [RFC PATCH 2/2] fs: add partition switch libary, implement ls and fsload commands Stephen Warren
2012-10-11 13:33 ` Benoît Thébaudeau
2012-10-11 16:47 ` Tom Rini
2012-10-11 16:57 ` Stephen Warren
2012-10-11 17:05 ` Tom Rini
2012-10-11 17:45 ` Benoît Thébaudeau [this message]
2012-10-13 19:26 ` Pavel Herrmann
2012-10-15 15:43 ` Stephen Warren
2012-10-13 0:31 ` [U-Boot] [RFC PATCH 1/2] fs: delete unused Makefile Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=498910150.6648038.1349977509948.JavaMail.root@advansee.com \
--to=benoit.thebaudeau@advansee.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.