From: Rob Herring <robherring2@gmail.com>
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 14:18:01 -0500 [thread overview]
Message-ID: <5081A769.901@gmail.com> (raw)
In-Reply-To: <5081864F.4090708@wwwdotorg.org>
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?
> Re: refactoring of the interface to the filesystem code: I'm curious
> what the DM-related plans are for filesystems. It seems that any such
> refactoring would be part of that work. Unfortunately I haven't been
> paying any attention to who might be proposing doing what and when
> there. Would it be appropriate to defer any fs-related API changes
> until any DM+fs rework went it to avoid conflicts or duplicate work?
I've had the same questions as well...
Rob
next prev parent reply other threads:[~2012-10-19 19:18 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 [this message]
2012-10-19 19:26 ` Stephen Warren
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=5081A769.901@gmail.com \
--to=robherring2@gmail.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.