On Fri, 2011-02-11 at 15:13 -0600, Brian King wrote:
> On 02/10/2011 01:38 PM, Nicholas A. Bellinger wrote:
> > On Thu, 2011-02-10 at 13:15 -0600, Brian King wrote:
> >> On 02/10/2011 06:21 AM, FUJITA Tomonori wrote:
> >
> > Hi Brian,
> >
> > <SNIP>
> >
> >>> +
> >>> +static int ibmvscsis_new_cmd_map(struct se_cmd *se_cmd)
> >>> +{
> >>> + struct ibmvscsis_cmnd *cmd =
> >>> + container_of(se_cmd, struct ibmvscsis_cmnd, se_cmd);
> >>> + struct scsi_cmnd *sc = &cmd->sc;
> >>> + struct iu_entry *iue = (struct iu_entry *)sc->SCp.ptr;
> >>> + struct srp_cmd *scmd = iue->sbuf->buf;
> >>> + int ret;
> >>> +
> >>> + /*
> >>> + * Allocate the necessary tasks to complete the received CDB+data
> >>> + */
> >>> + ret = transport_generic_allocate_tasks(se_cmd, scmd->cdb);
> >>> + if (ret == -1) {
> >>> + /* Out of Resources */
> >>> + return PYX_TRANSPORT_LU_COMM_FAILURE;
> >>> + } else if (ret == -2) {
> >>> + /*
> >>> + * Handle case for SAM_STAT_RESERVATION_CONFLICT
> >>> + */
> >>> + if (se_cmd->se_cmd_flags & SCF_SCSI_RESERVATION_CONFLICT)
> >>> + return PYX_TRANSPORT_RESERVATION_CONFLICT;
> >>
> >> Does this imply the driver supports scsi reservations? If it supports SCSI-2 reservations,
> >> there is a capability that could be set in the capabilities MAD to advertise this
> >> fact such that it can be used by the client.
> >>
> >
> > Absoulutely, the target core struct se_device backends being serviced as
> > VSCSI LUN would normally return SCSI-3 from INQUIRY data, and support
> > the full set of persistent reservations and CRH=1 (Compatible
> > Reservations Handling) in drivers/target/target_core_pr.c code.
> >
> > Also, we are able to explictly limit individual struct se_device
> > backends to disable PR and only use the older SCSI-2 reservations, but I
> > don't think we have a way to do this on a fabric module wide basis just
> > yet.
> >
> > Is this something we should be doing for this code..?
>
> Disregard my previous comment. It looks like current client should handle reservations
> just fine without any further changes.
So is that an ack for putting this in scsi-misc ... or did you want to
do more testing first?
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
