public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox