-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/18/12 16:12, Rob Herring wrote:
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@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.
I too would like to see more clean-up, and I do expect progress down that line, in this area, from Stephen as part of this being accepted. Unless the two of you would like to start collaborating on a slightly different path?
- -- Tom