From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Date: Thu, 18 Oct 2012 18:12:34 -0500 Subject: [U-Boot] [PATCH V2 3/3] fs: add partition switch libary, implement ls and fsload commands In-Reply-To: <20121018230146.GY27770@bill-the-cat> 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> Message-ID: <50808CE2.3020203@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. Rob