From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH V7 3/7] libxl: add pvusb API
Date: Thu, 8 Oct 2015 15:54:07 +0100
Message-ID: <1444316047.1410.220.camel@citrix.com>
References: <1443147102-6471-1-git-send-email-cyliu@suse.com>
	<1443147102-6471-4-git-send-email-cyliu@suse.com>
	<22038.32910.375958.407732@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <22038.32910.375958.407732@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Chunyan Liu <cyliu@suse.com>
Cc: jgross@suse.com, wei.liu2@citrix.com, george.dunlap@eu.citrix.com, xen-devel@lists.xen.org, jfehlig@suse.com, Simon Cao <caobosimon@gmail.com>
List-Id: xen-devel@lists.xenproject.org

On Thu, 2015-10-08 at 15:41 +0100, Ian Jackson wrote:

> > +libxl_device_usbctrl *
> > +libxl_device_usbctrl_list(libxl_ctx *ctx, uint32_t domid, int *num)
> > +{
> 
> This function should return an rc, and the list should come in an out
> parameter.

For better of worse libxl.h defines the general form of a device API to
include list looking like this (search for "Querying").

If this were for an actual device I'd be adamant that it should follow that
pattern.

Since this is part of a new "controller" abstraction we do in theory have
the freedom to do things differently, but it seems to me that having
something as basic as the list operation differ for devices vs. controller
would do more harm than good even if the controller interface is strictly
better. IOW I'm willing to be convinced otherwise but right now I'm pretty
sure how it is above is the preferable extension to our API.

> > +            const char *tmp, *be_path;
> > +            const char *fe_path = GCSPRINTF("%s/%s", path, *dir);
> > +
> > +            libxl_device_usbctrl_init(usbctrl);
> > +            usbctrl->devid = atoi(*dir);
> > +
> > +            tmp = READ_FRONTEND(gc, "backend-id");
> > +            if (!tmp) goto outerr;
> > +            usbctrl->backend_domid = atoi(tmp);
> > +
> > +            tmp = READ_BACKEND(gc, "usb-ver");
> > +            if (!tmp) goto outerr;
> > +            usbctrl->version = atoi(tmp);
> > +
> > +            tmp = READ_BACKEND(gc, "num-ports");
> > +            if (!tmp) goto outerr;
> > +            usbctrl->ports = atoi(tmp);
> 
> There are 4 nearly identical stanzas here.  I think a more
> comprehensive would be helpful.  Maybe a global macro READ_SUBPATH_INT
               ^MACRO?

Ian.