This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Jun Kamada <kama@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [Patch 0/7] pvSCSI driver
From: Steven Smith <steven.smith@xxxxxxxxxxxxx>
Date: Wed, 27 Feb 2008 11:16:10 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 27 Feb 2008 03:17:21 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080218190633.E761.EB2C8575@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080218190633.E761.EB2C8575@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> I will post total seven patches for new pvSCSI driver on following 
> E-mails.
Thanks for doing this, being able to pass SCSI devices through to
guests is likely to be a useful facility.

I have a couple of comments on the design:

-- You've ended up re-implementing a lot of Linux SCSI stuff in the
   backend.  I don't understand why this was necessary.  Would you
   mind explaining, please?

-- The code seems to be a bit undecided about whether the exposed
   devices are supposed to represent SCSI adapters or SCSI targets.
   It looks like the frontend initially tries to treat them as a bunch
   of targets, and then conditionally gloms them back together into
   hosts depending on xenstore fields?  Having a host per target would
   make sense, as would having a single host with all of the targets
   hanging off of it, but I don't understand why this split model is
   useful.  Perhaps I'm just missing something.

-- I don't understand the distinction between comfront and scsifront.
   What was the reason for this split?

-- There don't seem to be many comments in these patches.  Xen and
   Linux are both generally pretty comment-light, but an entire new
   device class without a single meaningful comment still kind of
   stands out.

I'll reply to the individual patches with more detailed comments.  A
lot of my complaints will doubtless turn out to just be because I'm
not very used to Linux SCSI.  I've not looked at the xend changes,
because I'm not really competent to evaluate them.


Attachment: signature.asc
Description: Digital signature

Xen-devel mailing list