[U-Boot] [PATCH V4 3/3] fs: add filesystem switch libary, implement ls and fsload commands

From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V4 3/3] fs: add filesystem switch libary, implement ls and fsload commands
Date: Tue, 30 Oct 2012 14:29:54 -0700	[thread overview]
Message-ID: <509046D2.4070303@ti.com> (raw)
In-Reply-To: <5090440B.3070707@wwwdotorg.org>

-----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 <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 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-----