[U-Boot] [PATCH V4 3/3] fs: add filesystem switch libary, implement ls and fsload commands
Tom Rini
trini at ti.com
Tue Oct 30 22:29:54 CET 2012
-----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 at 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-----
More information about the U-Boot
mailing list