[U-Boot] [U-Boot, 3/9] nand: add a hw specific subcommand to the nand command.

Scott Wood scottwood at freescale.com
Thu Aug 4 21:42:35 CEST 2011


On 08/04/2011 12:40 AM, Heiko Schocher wrote:
> Scott Wood wrote:
>> What if there are multiple such commands?  You'd end up with "nand hwfunc
>
> Then we would have a (as hwfunc is a nand subcommand) hwfunc
> subcommand(s) ...

The question was rhetorical, as the next sentence indicates -- unless 
you had a different answer, of course.

>> foo<args>", which is getting a bit unwieldy.  Having only one might
>
> Why?

The "hwfunc" doesn't really tell the user anything, it's an internal 
implementation detail of where in the code the command is implemented. 
It's verbosity without benefit.

> (I don;t know, if we get really more then one hwfunc...)

You later say a plain "nand hwfunc" would print a help message, so that 
plus one real command makes two...

>, but if we define all over the code some (board, soc, arch,...) specific
> nand commands, we lose track ...
> and with the "nand hwfunc" we have one place where we have to look ...

More like one thing to grep for, and you'll still need to limit the 
files grepped so you don't get irrelevant results from other boards or 
controllers.  Why not just search those files for U_BOOT_CMD?

>> actually be worse: what does a plain "nand hwfunc" do?
>
> A plain "nand hwfunc" should print the help message (if we have more
> subcommands under "nand hwfunc"), if we have only one, it returns
> as usual in uboot, actual state ...

"actual state" of what?  We haven't gotten to the point of actually 
defining a command yet.

> nand hwfunc [rbl/uboot]
>           switch between rbl/uboot nand read/write functions
>
> cam_enc_4xx>  nand hwfunc
> uboot

Again, I think "nand hwfunc" conveys little information about what it's 
actually going to do, versus something like:

=> nandrbl
off

At least "nand hwfunc type" or "nand hwfunc rbl" would be more 
informative, but I question the benefit that the verbosity buys us.

Why do you need alternative implementations of read/write functions, BTW?

> cam_enc_4xx>
>
>> What if there are multiple commands, but which belong in different places
>> (e.g. one defined by the board, one defined by the controller driver)?
>
> Maybe something like this?
>
> nand hwfunc arch ...
> nand hwfunc board ...
> nand hwfunc ctrl ...
> nand hwfunc soc ...
> [...]
>
> each hwfunc subcommand added through an define ...

So now it's "nand hwfunc ctrl type rbl"?  Just to avoid grepping for 
U_BOOT_CMD?

Or by "one place to look" are you talking about as a user in the help 
output?  If you insist on the command appearing as a proper "nand" 
subcommand, how about dropping "hwfunc" and letting other pieces of code 
register on a chain of handlers?  Anything that isn't recognized gets 
passed on to the next link in the chain.

-Scott



More information about the U-Boot mailing list