On Tue, 6 Aug 2002, Tim Hockin wrote:
> > If you ever sell a controller that contains an address that was
> > not allocated to the 'producer', somebody is going to get very
> > angry. This means, to me, that if you ever write a new MAC address
> > to that card/board, you had better throw it away when you are done.
>
> As a developer of integrated systems, it is imperative the we be able to
> re-program EEPROMs and MAC addresses. Cobalt systems all have Cobalt as
> the MFR section of the MAC address. Sun Systems all have Sun. (insert pokes
> about whether Cobalt is Sun here...)
>
> > It's easier to make sure that the MAC address doesn't get changed.
> > You still "screw the comittee" locally, but you don't modify the
> > hardware.
>
> Other things get stored in the EEPROM - for example, Wake-on-Lan options.
> Just to name one.
>
If you really are what you say you are, then you know that you
cannot use a MAC address that has not been assigned to your
company.
And, as a developer or "integrated systems", I do program MAC
addresses into AMD PCnet32 SEEPROMS and I do have a batch of
MAC addresses assigned to Analogic and I do known what I am
talking about.
The Linux pcnet32 driver does not have this capability so I
had to add that capability for our purposes. I would not
advise putting such a driver in the standard kernel.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:34 EST