[U-Boot] is there any issue with creating and using more than one hashtable?

[Robert P. J. Day]

On Sat, 1 Oct 2016, Wolfgang Denk wrote:

> Dear Robert,

... snip ...

> Actually the TFTP will not access the environment directly to
> determine the boot parameters like bootfile, ipaddr, gatewayip,
> netmask, serverip, etc.; instead, it uses internal variables.  So
> your environment settings for "ipaddr" and "gatewayip" may contain
> totally different values than the variables net_ip resp.
> net_gateway which get used by the TFTP code.
>
> These variables get set through the U_BOOT_ENV_CALLBACK functionality,
> i. e. as a callback whenever the corresponfing variable gets set.
> "setting" here means that the value in the hash table gets changed -
> see function _compare_and_overwrite_entry() in "hashtable.c":
>
> 244                         /* If there is a callback, call it */
> 245                         if (htab->table[idx].entry.callback &&
> 246                             htab->table[idx].entry.callback(item.key,
> 247                             item.data, env_op_overwrite, flag)) {
> 248                                 debug("callback() rejected setting variable "
> 249                                         "%s, skipping it!\n", item.key);
> 250                                 __set_errno(EINVAL);
> 251                                 *retval = NULL;
> 252                                 return 0;
> 253                         }
>
>
> So when you insert variable sof these registered names into your
> alternative hash table using the common code, then the respective
> callbacks will fire in the same way as if you had changed the
> environment settings through a setenv command.

  just to follow up, the simple solution for me would be to *not*
create that second hashtable with recognized u-boot variable names
like "ipaddr", "gatewayip", "serverip" unless i absolutely plan on
using those new values.

  an even simpler solution would be to skip the second hashtable
creation altogether, walk through my first hashtable (which should
have no conflicting variable names), and in one step, translate those
names and add them to the current environment.

  this is what i use to add/modify a new env variable -- is this the
correct approach, to add it to the "env_htab" hashtable?

  int
  add_entry_to_env(ENTRY* e)
  {
        ENTRY*  ep;

        printf("Adding stuff k: [%s], d: [%s] to env.\n", e->key, e->data);
        hsearch_r(*e, ENTER, &ep, &env_htab, 0);

        return 0;
  }

if that's the way to do it, i'll just do away with the second
hashtable and avoid the issue altogether.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================