[U-Boot] [RFC] env: Group environment variables

[John Schmoller]

On Thu, 2009-11-05 at 20:57 +0100, Wolfgang Denk wrote:
<snip>
> 
> > 2) Trying to figure out which enviroment variables have already been printed
> > in groups is less than elegant.  Currently, it's a brute-force approach of
> > looking through every entry until a variable is found in a group or not.
> > Suggestions for cleaner algorithms here would be appreciated.
> 
> The repeated scanning and comparing doesn't make much sense to me.
> Probably it makes more sense to use a more suitable data structure
> here.  How about performing a linear scan of the environment only
> once and convert it into a more easily processable data structure, say
> a hash table or a binary tree or whatever, and then operate on this.
> Here you can easily add additional flags like a pointer which group the
> variable belongs to (if any).
> 
> Also, this would make it easier for example to print a sorted list.
> 
> Eventually we should _always_ do that, i. e. replace the standard
> copy operation as done in env_relocate*() by a function that not only
> copies the environment, but converts it into a new internal
> representation. This might be beneficial to accelerate access to
> variables, too.

This is an excellent suggestion.  I'll see what I can whip up.

> 
> => print only a list of groups
> 
> > If env_groups is defined, none of the grouping variables will be printed.
> > This seemed to clutter up the printenv output.
> 
> I don't think this is a wise decision. Having "magic" variables which
> cannot be seen an idea I dislike. I think the standard "printenv"
> (without args) should print the grouping variables as first block.

Ok, I'll group the grouping variables into a group of their own.

> Also, it would be nice if "prontenv" now would allow to print a group,
> i. e. in your example something as "printenv net pci" should be
> supported.

This is already (accidentally :) supported.  a "printenv $net" would do
just what you state.

> > Grouping environment variables will almost certainly lead to a reqirement for
> > bumping up CONFIG_SYS_MAXARGS.
> 
> ...which raises the question why there is such a static limit in the
> first place. Yes, it was trivial to implement, but maybe this can be
> improved? Artificial limits on line lengths and numbers of arguments
> are a nice thing - to remove :-)
> 
> 
> Best regards,
> 
> Wolfgang Denk

John