[U-Boot] [PATCH V2 3/3] fs: add partition switch libary, implement ls and fsload commands

[Rob Herring]

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