On Wednesday 11 February 2009 00:45:05 Ben Warren wrote: > Mike Frysinger wrote: > > On Tuesday 03 February 2009 14:40:00 Mike Frysinger wrote: > >> i think we can agree that this does not scale at all. if, however, we > >> change the global data to something like: > >> typedef struct bd_info { > >> ... > >> #ifdef CONFIG_NET_MULTI > >> uchar bi_enetXaddr[CONFIG_NET_MULTI_MAX][6]; > >> # define bi_enetaddr bi_enetXaddr[0] > >> #else > >> uchar bi_enetaddr[6]; > >> #endif > >> ... > >> }; > > > > Ben: does this sound reasonable ? if so, i can start a patch series > > moving in this direction ... > > Thanks for tackling this cluste...@#. I'm not crazy about the > CONFIG_NET_MULTI_MAX, but then I'm not really sure why the ethernet > addresses exist in global data on boards with CONFIG_NET_MULTI. The net > library doesn't use them, most (maybe all?) of the drivers don't look at > it. Some common code does, but does it need to? Maybe it's needed to > pass to some operating systems? This is an example of something that > could use some serious refactoring, but I expect it's an onion with > many, many layers. OTOH, if you're going to change the name of a > variable in global data, you'll find out really fast where it's used. > Maybe we can gut it completely? I'm lacking in historical perspective > and my world view is pretty limited, so hopefully others (read WD) will > chime in.
i provided a backwards compat define so no code would break: # define bi_enetaddr bi_enetXaddr[0] but simply dropping all bi_enet*addr consumption in global data sounds like one way of tackling the situation. i see the structure as kind of a binary cache of the environment. but as a cache, it certainly shows today that it gets out of sync and many places use only one or the other. and with the utility functions i proposed, transitioning over to having the env be the only storage location wouldnt be too bad at all i dont think. -mike _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot