Re: [PATCH] libsas: add host SMP processing

[FUJITA Tomonori <tomof@acm.org>]

On Sat, 29 Dec 2007 09:44:32 -0600
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Sat, 2007-12-29 at 14:24 +0900, FUJITA Tomonori wrote:
> > From: James Bottomley <James.Bottomley@HansenPartnership.com>
> > > --- a/drivers/scsi/libsas/sas_expander.c
> > > +++ b/drivers/scsi/libsas/sas_expander.c
> > > @@ -1896,11 +1896,9 @@ int sas_smp_handler(struct Scsi_Host *shost, struct sas_rphy *rphy,
> > >  	}
> > >  
> > >  	/* no rphy means no smp target support (ie aic94xx host) */
> > > -	if (!rphy) {
> > > -		printk("%s: can we send a smp request to a host?\n",
> > > -		       __FUNCTION__);
> > > -		return -EINVAL;
> > > -	}
> > > +	if (!rphy)
> > > +		return sas_smp_host_handler(shost, req, rsp);
> > > +
> > 
> > I have one related question.
> > 
> > Currently, bsg doesn't return an error to user space since I had no
> > idea how to convert errors such as EINVAL and ENOMEM into
> > driver_status, transport_status, and device_status in struct sg_io_v4.
> > I think that it's confusing that bsg don't return an error even if SMP
> > requests aren't sent (e.g. devices are offline).
> > 
> > Do we need to map errors to the current error code in scsi/scsi.h
> > (like DID_*) or define a new one for SMP?
> 
> Neither, I think ... the DID codes are only for things that actually
> pass through the SCSI stack.  The way you implemented the smp functions
> in bsg, they're direct queue handlers themselves (Incidentally, that's
> another point about this: I think almost every use of bsg like this is
> going to be for SG_IO only, so it makes sense to move the actual queue
> handler into bsg, since they'll all share it).
> 
> The attached is the simplest patch that implements this.  However, it
> unfortunately can't be applied yet ... the current SMP tools send
> receive buffers too large and libsas actually returns a data underrun
> error (which is now propagated).

bsg read/write interface doens't return errors in this way (compatible
with sg3 read/write interface). If we support only SG_IO for non SCSI
request/response protocols, then that's fine.