On Mon, 16 Apr 2007, David Miller wrote: > From: Andrew Vasquez <andrew.vasquez@xxxxxxxxxx> > Date: Mon, 16 Apr 2007 14:10:49 -0700 > > > Ok, how about the following patch based on the one you posted which > > adds the codes to retrieve the WWPN/WWNN from firmware on SPARC, and > > also adds the module-parameter override I mentioned above. > > > > Perhaps the module-parameter should be set to non-zero in the case of > > SPARC, to take care of your system configurations? > > I think it should default to non-zero always, in fact the option > is completely pointless. > > The guy who hits this had a system which worked previously, and you're > explicitly breaking it. That's wrong. Sorry, 'it' didn't work... 'It' *never* did. > How can you not see that this quality of implementation decision > you're making stinks? You're defending a position which itself left users with a false sense of security and comfort. This is a *real* problem from an enterprise perspective where FC reigns. Fine, I'll agree that wacking-users (and I'll wager the outliers) with a 2x4 was a bit extreme, but I'd much rather handle those users on a case-by-case basis, either by: * If dealing with a PCI card, directing a user to a support staff at QLogic to resolve the NVRAM issues. * If it's some on-board ISP with no NVRAM, as was your SPARC case, then add *proper* codes to retrieve the data from some secondary persistent store. - 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
