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

Stephen Warren swarren at wwwdotorg.org
Mon Oct 15 18:47:49 CEST 2012


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.


More information about the U-Boot mailing list