NetBSD support for Suns with dead IDPROM batteries

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 <[email protected]>