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

From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2 3/3] fs: add partition switch libary, implement ls and fsload commands
Date: Thu, 18 Oct 2012 16:01:46 -0700	[thread overview]
Message-ID: <20121018230146.GY27770@bill-the-cat> (raw)
In-Reply-To: <507C3E35.70300@wwwdotorg.org>

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121018/e92c752d/attachment.pgp>