Re: [Xen-devel] [Patch 4/7] pvSCSI driver

[Steven Smith <steven.smith@xxxxxxxxxxxxx>]

> > > +int do_comfront_cmd_done(struct comfront_info *);
> > > +
> > > +static inline int GET_ID_FROM_FREELIST(struct comfront_info *info)
> > Why is this all-caps?  It's not a macro.
> That would just have been cut&pasted from the linux sources... I did the
> same in the windows PV drivers :)
Ah, okay.

Poking around a little, it looks like the blkfront in upstream Linux
uses lower-case get_id_from_freelist().  I'm not sure whether it's
better to be consistent with that or consistent with the other drivers
in our tree.  I'd probably go with upstream, but either's pretty
valid.

> > > + for (i = info->ring.rsp_cons; i != rp; i++) {
> > > +
> > > +         ring_res = RING_GET_RESPONSE(&info->ring, i);
> > > +
> > > +         if (info->shadow[ring_res->rqid].cmd ==
> VSCSIIF_CMND_SCSI) {
> > > +                 if (scsifront_cmd_done(info, ring_res)) {
> > > +                         BUG();
> > > +                 }
> > > +         } else {
> > > +                 __sync_cmd_done(info, ring_res);
> > Can this ever happen?
> Well... a rogue frontend could pass all manner of crap to the backend.
> Best to check for these things.
This *is* the frontend, unless I'm very, very confused.

> The other option for VSCSIIF_CMND_SCSI is a reset, but there is some
> debate as to whether a frontend using a single device on a physical
> scsi bus should be allowed to initiate a bus reset...
Yeah, an LU reset might be a better idea, if the underlying device can
handle it.

Speaking of which, would it be a good idea to expose the tagged
command queueing stuff?  I'd guess probably not, but I don't really
understand SCSI well enough to be sure.

Steven.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel