Michael Reed wrote:
I'm curious about the problem you're trying to solve. Generally a missing WWN,
I'm writing two SAS HBA drivers, Marvell 6440 and Broadcom 8603/HT1100,
and must deal with this scenario.
as having a unique WWN should be a product requirement, is an indicator of
a problem. Shouldn't the proper solution be to have the card repaired?
Arbitrarily assigning a WWN could mask or introduce other problems, in particular
with regard to storage connectivity.
If you are an admin suffering from the /common/ problem of missing or
invalid NVRAM, would you rather wait for card repair or get it going
immediately?
The standard Linux policy for unique ids like ethernet MAC has been, for
the 98% case where you have a useful MAC from the hardware, of course
use it. For the 2% case, you give the admin solutions for supplying a
useful MAC.
Mirroring decades of ethernet NIC history, the HBA silicon and the
source of the unique id are most often vastly different. Normally it is
a different chip on the same board, but sometimes the unique id source
is not on the same board at all.
For those reasons and more, Linux users have a LONG history of running
into situations where, for one reason or another, their silicon is fine
but their unique id is not. I've heard them all:
- hw from government auction, had NVRAM intentionally wiped
- hw resale w/ NVRAM wiped by paranoid corporate IT staff
- hw with NVRAM chip missing
- old hw out of warranty
- old dev kit (they rarely ship with useful NVRAM data)
- and plenty more
We have to behave sanely in the 2% case. "refuse to operate" is just
not an option, when this problem case is so historically clear, and so
easy to work around.
Linux drivers have to continue operating long after support contracts
run out, long after chip EOL, and sometimes, long after companies go out
of business.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
