On 10/15/2012 10:33 AM, Rob Herring wrote:
On 10/11/2012 01:59 PM, Stephen Warren wrote:
From: Stephen Warren swarren@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.