[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:23:28 -0700	[thread overview]
Message-ID: <50808F70.3040704@ti.com> (raw)
In-Reply-To: <50808CE2.3020203@gmail.com>

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQgI9vAAoJENk4IS6UOR1WLWgP/2MTdElBAG+EYGY8aoLuT0yA
HSLRjz63xdM2Y2sQnI5OTyKQjuAGPjpGlZg9UHkrbBiyGixdcZwjZ+zZlVsjUIRC
eL9Zd5SByyZkYdw+d5BHFt2R6nTS7PTLGxKcfGnz03NKgY8+jP3gGjkY8xx6Egv8
z6SOxSPXAM16A2YZBkR+1JIR58ZQ4rBVTl1pOuFoFugC11ALcpCYqDfkCc/iOcSj
IPdD9/hfU75NBTHuLRyeBjO0s2Z5OTrPR/SNyQhCxouLxiIRyBvACIbKxBHJByl8
8e8W5k+zBw5+FvA+ioh7JCKFNzgwDf7rVc4hIX98lrfvB+bUUJ8AJrLdDVhybf84
BdDSpJ8Pq0ShQZXw3DbylnHhG8H3JuoH0ZfqHE8ws0IfdQQ8QhEosiV1h8x9sc0u
zBLPY9ZkF75HKoHi0B0Aq+atzSUOy2I5PpsaeaX1Lyi4tLhsupE5nXuS1Pv8Jp+3
zwPoGRVZavpEfhvcrNNCTdfWDaTuhzOEM/PvGHrJQimpSw7YC03617muMjwVNk4B
uJVY9k5iuNCpQOiAxm7/XV0+L9U2FFpj733f6w85p0bCLRnj2JTIyLy6bGNFJlP7
S3BLnPaHgbH90dRJRnvnnIT31Qove/9/2DxKIE1DYWmfULPNPTVkscUigA5Bw/16
BYU/4XZShmDnzPHJBTef
=OMSB
-----END PGP SIGNATURE-----