On 10/19/2012 01:18 PM, Rob Herring wrote:
On 10/19/2012 11:56 AM, Stephen Warren wrote:
On 10/18/2012 05:23 PM, Tom Rini wrote:
On 10/18/12 16:12, Rob Herring wrote:
On 10/18/2012 06:01 PM, Tom Rini wrote:
...
> On 10/11/2012 01:59 PM, Stephen Warren wrote: >> 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.
...
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,
Which clean-up exactly?
The only duplication I see here is that ext2load/fatload could be modified to simply call into do_fsload. That'd be pretty simple, I think, assuming the behaviour change was OK (e.g. fatload would suddenly support either FAT or ext2*), and that cmd_fs.c and fs.c would both always be pulled in.
Can't you make do_fsload support either specifying the fs for legacy use or detecting it on the new commands?
Yes, I suppose I could:
* Add a bit-mask of legal filesystems as a parameter to fs_set_blk_dev().
* Move the body of do_fsload() into some common called by do_fsload(), do_ext2load(), do_fatload(), each passing in the appropriate bit-mask, which gets passed down to fs_set_blk_dev().
That'd be easy, and probably entail only extremely minimal code-size increases for an ext2-only or FAT-only build; just a few bytes for a few more function calls. Sound like a plan?