[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Patch 4/7] pvSCSI driver
> > > +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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |