Dear Michael, In message <bf1393770cc04a3fb2b271d25fa6a...@walle.cc> you wrote: > > What is the will of the user in this case?
In which case? When the user does not bother to set a specific MAC address and let the system gernerate a random one? Well it is his (maybe concious, maybe not) decision... > It is the will of the > developer to make the board more robust. Maybe, maybe not. Often this is just a convenient method for the board manufacturer to provision his boards with valid data. If it makes sense to ship boards in such a state to the end user is another question. > > Maybe you explain what exactly the ``error with "net list"'' is, > > Michal mentioned it here [1]. Yes, and he also provided a valuable and correct comment: | And if you don't want to use this feature just don't enable it via | CONFIG_NET_RANDOM_ETHADDR. This say all, no patches needed. > > considering the fact that it is U-Boot which determins the > > "correct" MAC address and passes it to Linux. And if the user > > configures U-Boot such that a random MAC address is used, then this > > _is_ the correct MAC address, as normally (*) U-Boot is just a tool > > that does what the user requests. > > Only that the user doesn't do it but the board developer/OEM. I.e. > there is no valid MAC address to pass to linux. Why do you continue to claim that the MAC address used in U-Boot is not valid? Of course it is. This is similar to the situation where appliances sip with default passwords like ADMIN/ADMIN. The user can ignore the documentation which has bright red warning notes in CAPITAL LETTRRS that he *must* configure secure passwords... > It is really just > for having netconsole running (or maybe you'll need networking for > to rescue your failed EEPROM or whatever). This is one of many possible use cases. Board provisioning is another one. > I think, we have to distiguish between two use cases here: > (1) make networking in u-boot work "somehow", to have a last > resort recovery, esp. required for netconsole where > the user cannot set the mac address by hand. > (2) normal use case, where drivers simply doesn't have any > other source for the mac address and need to fall back > to a random one. There are many more use cases. And it may be intentional to use a random MAC address. There is this old rule: "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn If you don't like it, then disable the feature. It is nonstandard anyway, i. e. only intended for special cases / qualified users. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The day-to-day travails of the IBM programmer are so amusing to most of us who are fortunate enough never to have been one - like watching Charlie Chaplin trying to cook a shoe.