From: Stephen Warren <swarren@wwwdotorg.org>
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 10:57:05 -0600 [thread overview]
Message-ID: <5076FA61.7080007@wwwdotorg.org> (raw)
In-Reply-To: <5076F80D.1030304@ti.com>
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.
next prev parent reply other threads:[~2012-10-11 16:57 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 [this message]
2012-10-11 17:05 ` Tom Rini
2012-10-11 17:45 ` Benoît Thébaudeau
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=5076FA61.7080007@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--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.