Dear Tom,
In message <20211117123548.GX24579@bill-the-cat> you wrote:
>
> > Why would you expect any "do not use" note? Locally adminitered MAC
> > addresses (even when randomly chosen) have been created for good
> > reason, so they should be usable.
>
> Because as been noted in either this thread, or the other long thread,
> the user does not want to confuse Linux with this emergency random MAC?
Classical answer: Don't do it, then.
If the user does not want to pass a MAC address to Linux, he should
simply not do it. Deleting "ethaddr" from the environment should be
all that's needed. [And if this does not work, then I consider this
a bug that should be fixed.]
> > I'm afraid I do not understand what exactly you are proposing here?
>
> I'm objecting to changing our long standing behavior of NOT
> automatically passing the random MAC to the OS. That has always been
> user opt-in by using tools/gen_eth_addr and "setenv ethaddr ... ;
> saveenv". Especially since I don't know how many of those 200+ boards
> that enable CONFIG_NET_RANDOM_ETHADDR today are "enabled, but never
> used" vs "enabled, random MAC in U-Boot since we don't care/didn't
> notice, real MAC in Linux". So yes, another worry is that we have a
> class of boards in U-Boot where a random MAC is fine enough since it's
> rarely used/needed, but Linux can get the real MAC and now we'll be
> blowing that away. Or maybe we just have a ton of boards that
> copypasta'd that option in and didn't really think why.
Unfortunately we can only speculate about that [my guess is that
most of them are just copy/paste while brain in low power mode].
> > But I object to using a MAC address in U-Boot in a way that makes it
> > invisible to the user who uses documented APIs ("printenv ethaddr").
>
> Well, that's the API we've had for over 10 years, and it was a common
> problem in those earlier days with lots of SBCs where it was cheap to
> toss in a USB eth controller that didn't store a MAC anywhere. Now
> we're I believe hitting this due to FPGA stuff.
CONFIG_NET_RANDOM_ETHADDR has been added in 2015 with commit bef1014
"net: Implement random ethaddr fallback in eth.c"; from the changes
then I'm not sure if this was even USB related.
> > If we use some MAC address, it shall be possible to read it using
> > "printenv ethaddr" and to set it using "setenv ethaddr". Anything
> > else is inconsistent crap.
>
> Well, we've been inconsistent about the former for forever and there's
> a lot of implications to changing it now.
Yes. However, being bug-compatible is something we should not rate
too high.
[non-random signature used]
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 net result is a system that is not only binary compatible with
4.3 BSD, but is even bug for bug compatible in almost all features."
- Avadit Tevanian, Jr., "Architecture-Independent Virtual Memory
Management for Parallel and Distributed Environments: The Mach
Approach"
