From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 30 Oct 2012 14:29:54 -0700 Subject: [U-Boot] [PATCH V4 3/3] fs: add filesystem switch libary, implement ls and fsload commands In-Reply-To: <5090440B.3070707@wwwdotorg.org> References: <964860449.281207.1351628585903.JavaMail.root@advansee.com> <5090440B.3070707@wwwdotorg.org> Message-ID: <509046D2.4070303@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/30/12 14:18, Stephen Warren wrote: > On 10/30/2012 02:23 PM, Beno?t Th?baudeau wrote: >> Hi Stephen, >> >> On Monday, October 22, 2012 6:43:51 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. >>> >>> Replace the implementation of {fat,ext[24]}{ls,load} with this >>> new code too. > >>> diff --git a/fs/fs.c b/fs/fs.c > >>> +int do_fsload(cmd_tbl_t *cmdtp, int flag, int argc, char * >>> const > >>> + return 1; + + if (argc >= 4) { + addr = >>> simple_strtoul(argv[3], NULL, 0); >> >> 0 is just natural here. However, this raises the issue of the >> users of the legacy fat and ext commands, which used 16 here. So >> should we use 0 because it is cleaner, or 16 in order not to >> break compatibility for existing users? > > Oh yes, that is a problem. I feel I should be donning a brown paper bag here as well. > I think we should use 0 here for the new commands at least; it has > always annoyed me that U-Boot assumes that clearly non-hex values > (since there is no 0x) are actually hex. I often have to manually > convert values because of this (e.g. host-based ls decimal output > to U-Boot command input expecting hex without leading 0x.) I feel your pain (and have gotten in the habit of doing lots of printf + shell math) but don't like changing expectations on the users, even if they are seemingly odd (since they've gotten used to them too). > However, we do need to fix this for the existing legacy commands. > I suggest we either: > > a) Add a new parameter to do_fsload() indicating which base to > use. > > or: > > b) Assume base 0 if fstype==FS_TYPE_ANY, otherwise use 16. > > (a) is probably cleaner. > > For the environment variables, I suppose we need to continue to > explicitly request base 16 conversion, since those variables could > be used with either the old or the new commands. I agree with (a) along with adding to the help which parts are read in as decimal at the cli. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQkEbSAAoJENk4IS6UOR1W6RsP/3Smcwi5j2SMtVe0P+YjGHrX brNurEoFv60ezqEhssYjxwopTJJpl8Xo8kqS2pcY7JbR8DXszMhacoWhMDwqxqQD DS0tgbMXmXC+hSOs9nM6WY/auJUHbFkC4BbTCaxN8VZ2ovhX/3n//g6Jpbc7G4uC 5Lt0uYercP1NHVEeEoKAyWwklsndS2/+ywj4LN8GWfa7eA/GY0/RIhx56XCSHYLd ogXpOlRY0vZo0egj3a/UNMw3FLCy3XEOKQCGIU6TF5cYK+ZCS15irAFa+o1iv5oB am8Qsu6R6mQr3IgqmM91YV29KlhDYoAfNc8OHJovDYkSvqqon9M3Trr57b3mo0ko FYePs/w529yATS/FeuQgw62/dJd/dccNB/dvna7CjfOW/0B84R/xAAgCnPJn7Jhw +AOjGcILrNGAUQP7kcdNRDRKHelBN1JKsiJdnQpX1m70iAviFAJRV1tl5jktKu8j s57vLfN1uQ9qxcsZ7wyUKkFSfZm2AvdYAl85X9ATPYXKa6Z1acwECZbPXczwRHFm 7bdYZbB9dFIUrE8UMGqYbZUNVwcm+5i5d7pUHDD0rOzklyrqBgrQ/v4FzUSsQQdN eTM8DyrgCqCIbIz5mg63Mhykc20eRwTipp8Laflvp8+/nFUo21lxfvz1wbSMg/n1 /8mEDflYHo4fGKzq414r =J3B9 -----END PGP SIGNATURE-----