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

[Rob Herring]

On 10/18/2012 06:01 PM, Tom Rini wrote:
> On Mon, Oct 15, 2012 at 10:47:49AM -0600, Stephen Warren wrote:
>> On 10/15/2012 10:33 AM, Rob Herring wrote:
>>> On 10/11/2012 01:59 PM, Stephen Warren wrote:
>>>> From: Stephen Warren <swarren at 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 to test with.
>>>>
>>>
>>> This is exactly what I want to get to.
>>
>> That's good.
>>
>>> However, I think the first step
>>> should be to unify the filesystem api similar to the block device api.
>>> This would avoid the wrapper here and yet another copy of nearly
>>> identical code. Then we can unify the implementations of *ls and *load.
>>
>> I think we will always need some form of wrapper.
>>
>> At the very least, we will need fs_set_blk_dev() (or a function that
>> does the same thing under a different name) in order to probe which type
>> of filesystem is present, just like we have get_partition_info() for
>> partitions, which scans for all known forms of partition table.
>>
>> The only way to avoid wrappers for the other functions (ls, load) would
>> be if fs_set_blk_dev() were to set up some global variable pointing at
>> the filesystem implementation struct. If it did that, client code could
>> call directly into the filesystem rather than calling into the wrapper
>> functions to indirect to the correct filesystem. This might be a
>> reasonable design, although even if that is the long-term plan, I don't
>> think it precludes using the wrapper approach first, then refactoring
>> the wrapper away as functionality (e.g. fs_{probe,close}_{fat,ext4})
>> moves into the filesystem implementations; this seems like a good first
>> step on the way.
> 
> 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.

Rob