NetBSD support for Suns with dead IDPROM batteries

[Erik Fair <fair%netbsd.org@localhost>]

Many of the Suns that NetBSD/sparc & sparc64 support have dead IDPROM batteries 
at this point, and the IDPROM replacements are just expensive enough (if you 
can find them) that most people don't bother, especially when that cost is 
considered against the current value of the rest of the hardware and the 
performance thereof.

However, a dead IDPROM battery doesn't mean a dead computer - it just means the 
computer has got alzheimer's and can't remember its name (hostid) and Ethernet 
MAC address ... or a boot device other than the default. Very often, what one 
gets out of that situation is all zeros, or all ones (broadcast) Ethernet MAC 
address.

NetBSD, of course, doesn't care what the MAC address is. However, we know that 
broadcast (all ones) is nonsense and will not work (in fact, will likely cause 
other problems). We could, as a matter of extending the useful (well, 
operational) lifetime of these systems, sanity check the MAC address of Suns at 
boot time to make sure they're not broadcast/multicast (or all zeros), and if 
they are, assign something somewhat more sensible (e.g. 8:0:20: + the last 24 
bits of time_t from the root filesystem (since the TOD clock is likely to be 
wrong, too)).

I recognize that this won't help diskless, netbooted systems - they have to 
have a sensible MAC address as a condition of booting. It also makes the MAC 
address of these systems relatively unstable (I suggested (time_t & 0xffffff) 
as a way of avoiding MAC address collisions if there is more than one such 
system on the same LAN - if you've got a better suggestion for a source for 
additional bits in such a system, I'm ready to entertain it), so if you're 
providing IP addresses per MAC address with DHCP, or filtering on MAC 
addresses, you lose.

For those systems that have disks in the default boot configuration (e.g. 
appropriate internal SCSI bus id), this small change will extend the life of 
such hardware ... until something else fails.

What have I missed?

        submitted for your consideration,

        Erik <fair%netbsd.org@localhost>