Re: PATCH 4/5: scsi-scan-dont-att-pq-notcon

[Patrick Mansfield <patmans@us.ibm.com>]

On Wed, Apr 21, 2004 at 11:18:30AM -0500, James Bottomley wrote:
> On Wed, 2004-04-21 at 11:08, Kurt Garloff wrote:
> > But unfortunately James prefers yet another approach, where we add
> > a inq_pq field to struct scsi_device ...
> > Patrick did not like it, if I parsed his mail correctly. 
> > So we've conflicting requirements.

Yes.

> > I'll wait for this to be sorted. If it's only used at one place
> > (bus_match), I believe parsing it directly from the inquiry data
> > is perfectly fine. The code dupl in UL drivers was not.

And yeh I agree.

> 
> Well, I'm happy to have the debate.
> 
> My principle is that inquiry data should be abstracted as much as
> possible on the grounds that it's the hottest piece of the standard in
> terms of everyone grabbing fields to indicate extra features.  I'd like
> problems caused by inquiry field changes to be confined to scsi_scan.c
> (so we have a single parsing routine for common inquiry fields.  The
> thing I can definitely see someone wanting to do is to overflow either
> the type or pq field).
> 
> There's logic to parsing data where it's needed, but it makes it
> difficult to locate all the places when it changes...

So add a macro or inline function to parse the data, like a sdev_pq(sdev),
then we have one location for the parsing, and don't have to duplicate the
data. And if sdev->inquiry changes or goes away we need only change
sdev_pq().

-- Patrick Mansfield