From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2 3/3] fs: add partition switch libary, implement ls and fsload commands
Date: Fri, 19 Oct 2012 13:26:37 -0600 [thread overview]
Message-ID: <5081A96D.4070901@wwwdotorg.org> (raw)
In-Reply-To: <5081A769.901@gmail.com>
On 10/19/2012 01:18 PM, Rob Herring wrote:
> On 10/19/2012 11:56 AM, Stephen Warren wrote:
>> On 10/18/2012 05:23 PM, Tom Rini wrote:
>>> On 10/18/12 16:12, Rob Herring wrote:
>>>> On 10/18/2012 06:01 PM, Tom Rini wrote:
>> ...
>>>>>>> On 10/11/2012 01:59 PM, Stephen Warren wrote:
>>>>>>>> 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 to test
>>>>>>>> with.
>> ...
>>>>> Baring further discussion, I intend to grab this really soon,
>>>>> as it sounds like it's a functional starting point, however we
>>>>> wish to make this happen. Or am I not following? Thanks!
>>>
>>>> It's your call. I'd rather see clean-up first and features
>>>> second, but that's just me. Either way works. The amount of
>>>> duplication in u-boot just annoys me. Hopefully the DM work will
>>>> fix some of it.
>>>
>>> I too would like to see more clean-up,
>>
>> Which clean-up exactly?
>>
>> The only duplication I see here is that ext2load/fatload could be
>> modified to simply call into do_fsload. That'd be pretty simple, I
>> think, assuming the behaviour change was OK (e.g. fatload would
>> suddenly support either FAT or ext2*), and that cmd_fs.c and fs.c
>> would both always be pulled in.
>
> Can't you make do_fsload support either specifying the fs for legacy use
> or detecting it on the new commands?
Yes, I suppose I could:
* Add a bit-mask of legal filesystems as a parameter to fs_set_blk_dev().
* Move the body of do_fsload() into some common called by do_fsload(),
do_ext2load(), do_fatload(), each passing in the appropriate bit-mask,
which gets passed down to fs_set_blk_dev().
That'd be easy, and probably entail only extremely minimal code-size
increases for an ext2-only or FAT-only build; just a few bytes for a few
more function calls. Sound like a plan?
next prev parent reply other threads:[~2012-10-19 19:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-11 18:59 [U-Boot] [PATCH V2 1/3] fs: delete unused Makefile Stephen Warren
2012-10-11 18:59 ` [U-Boot] [PATCH V2 2/3] fs: separate CONFIG_FS_{FAT, EXT4} from CONFIG_CMD_{FAT, EXT*} Stephen Warren
2012-10-11 18:59 ` [U-Boot] [PATCH V2 3/3] fs: add partition switch libary, implement ls and fsload commands Stephen Warren
2012-10-11 19:40 ` Benoît Thébaudeau
2012-10-15 16:33 ` Rob Herring
2012-10-15 16:47 ` Stephen Warren
2012-10-18 23:01 ` Tom Rini
2012-10-18 23:12 ` Rob Herring
2012-10-18 23:23 ` Tom Rini
2012-10-19 16:56 ` Stephen Warren
2012-10-19 19:18 ` Rob Herring
2012-10-19 19:26 ` Stephen Warren [this message]
2012-10-19 20:09 ` Tom Rini
2012-10-20 8:39 ` Marek Vasut
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=5081A96D.4070901@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