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 <swar...@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! -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot