
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/11/12 09:57, Stephen Warren wrote:
On 10/11/2012 10:47 AM, Tom Rini wrote:
On 10/10/12 17:05, 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.
Signed-off-by: Stephen Warren swarren@nvidia.com --- There are a couple FIXMEs in here:
- In fs/fs.c, code is ifdef on CONFIG_CMD_FAT or
CONFIG_CMD_EXT2. This means that the new commands and code can only be enabled if the "legacy" {fat,ext2}{ls,load} are enabled. What we really want is CONFIG_FS_FAT and CONFIG_FS_EXT2 to enable the filesystem code, and then CONFIG_CMD_FAT, CONFIG_CMD_EXT2, CONFIG_CMD_FS to only affect the command implementations. However, that would require making every include/config/*.h that sets the current defines also set more. I suppose that's a fairly mechanical change though, so easy enough to implement. Does that seem like a reasonable approach to people?
How about a new CONFIG_CMD_GENERIC_FS for the new ls/fsload (and any later commands like write that get added) and once most filesystems are converted we can think about a transition plan?
Certainly.
The issue is that the filesystem code itself is conditionally included based on CONFIG_CMD_FAT and CONFIG_CMD_EXT4. This would require that in order to use the new generic commands, you also had to support the old non-generic commands in order to get a linkable result. Perhaps that's fine for now, but by separating the existing CONFIG_CMD_FAT into two (CONFIG_CMD_FAT, CONFIG_FS_FAT), we could avoid that requirement. As Benoit mentioned, perhaps we could arrange that CONFIG_CMD_FAT selects CONFIG_FS_FAT somehow, although I haven't looked at U-Boot's configuration system to see if that's possible yet.
Since we don't have Kconfig right now, it's not really easy to do that kind of thing. I think once we have more filesystems converted we can work out doing the mechanical separate of fs/ from common/ for fs code.
- -- Tom