From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 18 Oct 2012 16:23:28 -0700 Subject: [U-Boot] [PATCH V2 3/3] fs: add partition switch libary, implement ls and fsload commands In-Reply-To: <50808CE2.3020203@gmail.com> References: <1349981969-26113-1-git-send-email-swarren@wwwdotorg.org> <1349981969-26113-3-git-send-email-swarren@wwwdotorg.org> <507C3ACD.9070409@gmail.com> <507C3E35.70300@wwwdotorg.org> <20121018230146.GY27770@bill-the-cat> <50808CE2.3020203@gmail.com> Message-ID: <50808F70.3040704@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de -----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 >>>>> >>>>> 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-----