[Stgt-devel] [Patch 2/8 ] Combine INQUIRY into a common spc_inquiry routine.

[Ming Zhang]

On Sat, 2007-05-26 at 07:48 +1000, Mark Harvey wrote:
> On 5/26/07, Pete Wyckoff <pw at osc.edu> wrote:
> > markh794 at gmail.com wrote on Wed, 23 May 2007 13:01 +1000:
> > > Moved scsi_sn, scsi_id and d_sense (now sense_format) into a common
> > > struct with other INQUIRY related data.
> > [..]
> > > +static int osd_device_init(struct scsi_lu *lu)
> > >  {
> > > -     lu->d_sense = 1;
> > > +
> > > +     if (spc_device_init(lu))
> > > +             return -ENOMEM;
> > > +
> > > +     memcpy(lu->attributes->ProductIdent, "OSD", 16);
> > > +     lu->attributes->sense_format = 1;
> > > +     lu->attributes->version_desc1 = 0x0340; /* OSD */
> > > +     lu->attributes->version_desc2 = 0x0960; /* iSCSI */
> > > +     lu->attributes->version_desc3 = 0x0300; /* SPC-3 */
> > > +
> > >       return 0;
> > >  }
> >
> > Good stuff.  I like the common INQUIRY handling.  It was something
> > Tomo asked for once I added yet another inquiry handler for OSD.
> >
> > Another tweak that will be needed is the ability to support more
> > page codes.  OSD needs to provide 0xb0 and 0xb1.  This means
> > modifying 0x0 (supported VPD pages) to add two more supported pages
> > to the list.  And it needs very OSD-internal code to produce the
> > right responses for 0xb0 and 0xb1.  So I've been holding off pushing
> > that change because it is difficult to generalize well.  If you have
> > ideas, they would be most welcome.
> >
> > By all means, this patch is a step in the right direction, though.
> >
> >                 -- Pete
> >
> 
> Thanks for the vote of confidence.
> 
> As you may be aware, my main aim is to create a Virtual Library
> (Tape/CD/MO etc.)
> 
> The SSC devices will also require extra VPD pages...
> 
> I have not had any ideas regarding how to support multiple VPD pages
> which I feel is 'good'.
> 
> I was thinking yet another list, similar to the MODE list, but this
> seems a bit of an over-kill for a few bytes of data / VPD.
> 

> 
> The other concern I had regarding the SCSI Version, related to the
> underlying transport. At the moment, I have hard-coded iSCSI version,
> however it would be 'nice' to be able to insert which ever underlying
> protocol was being used to connect to the target...
> 
> Can anybody suggest an easy way of detecting the underlying protocol
> at runtime ?

u need front end pass this info to back end. for example, a run time
session opaque structure with a function to grab protocol string. 


> 
> Cheers
> Mark
> _______________________________________________
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/stgt-devel