Re: [PATCH RFC] cmd: fix net list command

[Wolfgang Denk <wd@denx.de>]

Dear Michael,

In message <bf1393770cc04a3fb2b271d25fa6a46c@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: wd@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.