From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 11 Oct 2012 10:05:37 -0700 Subject: [U-Boot] [RFC PATCH 2/2] fs: add partition switch libary, implement ls and fsload commands In-Reply-To: <5076FA61.7080007@wwwdotorg.org> References: <1349913907-25845-1-git-send-email-swarren@wwwdotorg.org> <1349913907-25845-2-git-send-email-swarren@wwwdotorg.org> <5076F80D.1030304@ti.com> <5076FA61.7080007@wwwdotorg.org> Message-ID: <5076FC61.9070807@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/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 >> >>> 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 --- There >>> are a couple FIXMEs in here: >> >>> 1) 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQdvxhAAoJENk4IS6UOR1WOFIP/0VjExqx5FZ+Lau4wFtV8dI0 v5+jfwDUtG0L3h/lTv9NJkX5j9duXJVOcAkB4hVeWFAqd/fSdI0mlajPvR1rpS/J luYFvR/XdlIoQe65CbrKhFEzHH3pwcbYXd/Zz9wx2cvxmTz7NvbM3KZsvECPpYtO CEqNClM2e5Q0ebE/XKZ5xG8qJVWZbs48i8kkmgHQHsiplGEdf7IzNgOqiSFL5rgF DT6oRacoAzOLBwMo5/ssIiT04GgM+3Nac1UV/4GPKiNt62k4p6OfniUN4sL6N6Yl oq8aFR3ZWGZgHdHO+y+pp+4MLAlvbv8PxMXHhw/ZCCHgLR9sodvWQl/Pn3C9TFTC 0LdYgMvft5FBBqffI+XuPMomdKYLmmHtAhlh7lly9L5GQYw8iU25cfXP8ZeBUOX+ aY4nX/Wp2s+vtXawWUVv01r0HRZZp3r6FJNAXWvE9m2cB+7HiZQD+nJvkV7ZZk7E 6WRdRlI8NTLn6Sfh42d6AzigsYfAm2Xwp6B1/gGix075E30yhB1KGdxs/SpQW+0+ tdtFXij/jtxAyabTLNTivAXO44l6IBurtlAZqXeI1ur6gEJa0L1Ju0Mi6rFO/Vrg aQ/KBo+1DM4QgXxYkcYPxJ+KIJKQdsmIWEmpni+sgaLBgO43Ebh+lkLKHCm5NB0l kaIgld2V1OQQDmg/j4yW =Tegq -----END PGP SIGNATURE-----