On Thu, 2009-12-10 at 07:01 -0600, Brian King wrote: > Michael Reed wrote: > > > > James Bottomley wrote: > >> On Fri, 2009-12-04 at 11:55 -0600, Michael Reed wrote: > >>> Yeah. I'm working on a patch for qla1280.c also. Probably others > >>> have been hit. It would have been nice if the patch author had > >>> fixed all the drivers instead of introducing this change and waiting > >>> for people to discover their last lun is now missing. > >> Actually, lets just revert this: > >> > >> commit 71c309995bff5b5e84253931888b6e8163ee1df0 > >> Author: Ed Lin <ed.lin@xxxxxxxxxxx> > >> Date: Fri Oct 9 15:23:27 2009 -0700 > >> > >> [SCSI] fix inconsistent usage of max_lun > >> > >> Which is causing all the problems. Perhaps we need to update the > >> documentation instead? > >> > >> James > > > > As much as I would whine about it, I think moving to a consistent > > usage of max_lun is a good thing. There are only about 140 references > > to max_lun in the cscope output so it wouldn't be that difficult > > for people to go through and fix up their drivers. And, I suspect > > a good portion will not require any change as they already either > > work correctly with sequential lun scan by design or have misinterpreted > > the meaning of max_lun, and thus will continue to work correctly > > with report lun scan with Mr. Lin's patch applied. > > The ibmvfc driver was using 0xffffffff to indicate it essentially had no limit > on the number of LUNs. It appears this can no longer be done with the commit > above since max_lun is an unsigned int. Right, I've pulled the commit. It was largely cosmetic ... moving what we actually do to match the documentation. However, since it appears everyone reads the code not the docs, the better course might be moving the documentation to match what we actually do. James -- 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
