James Bottomley wrote:
I'd suggest not:
jejb@mulgrave:~/git/linux-2.6/drivers/scsi/lpfc> git grep 'max_vports && vports'|wc -l
17
Assuming this secures agreement as a patch, I don't really want to wade
through another 16 patches for the remaining ones. You definitely can't
reduce the vport array length until they're all fixed.
What I hear is that it's not a problem, but it's a possible
micro-optimisation. Assuming the maintainer agrees, it's far better
just to fix everything at once. However, I'm equally happy to leave it
as is since there's no actual problem given the allocation definition.
What prevents the loop in lpfc_create_vport_work_array() from wandering
off the end of vports[], btw?
We refuse to create any vports beyond this number ... the iterator
counts the number of created vports (it's actually a firmware limited
number, I believe).
James
Agree. It's a style thing from one of the contributors to the driver. There
is no issue, I don't believe that optimizing 1 less pointer's worth of
allocation is a big deal (good, yes, but...). However, I do recognize it is a
much better coding style.
I'll roll the changes for it into the next driver patch set. (Yes, it is a
firmware limited number).
-- james s
--
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
