Re: generating a Linux WWN?

[Jeff Garzik <jeff@garzik.org>]

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