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