public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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 10:56:47 -0600	[thread overview]
Message-ID: <5081864F.4090708@wwwdotorg.org> (raw)
In-Reply-To: <50808F70.3040704@ti.com>

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.

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?

  reply	other threads:[~2012-10-19 16:56 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 [this message]
2012-10-19 19:18               ` Rob Herring
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=5081864F.4090708@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