[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC V2 3/5] libxl: add pvusb API



On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote:
> Add pvusb APIs, including:
>  - attach/detach (create/destroy) virtual usb controller.
>  - attach/detach usb device
>  - list assignable usb devices in host
>  - some other helper functions
> 
> Signed-off-by: Chunyan Liu <cyliu@xxxxxxxx>
> Signed-off-by: Simon Cao <caobosimon@xxxxxxxxx>
> ---
>  tools/libxl/Makefile         |    2 +-
>  tools/libxl/libxl.c          |    2 +
>  tools/libxl/libxl.h          |   58 ++
>  tools/libxl/libxl_internal.h |    6 +
>  tools/libxl/libxl_usb.c      | 1277 
> ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxlu_cfg_y.c   |  464 ++++++++-------
>  tools/libxl/libxlu_cfg_y.h   |   38 +-
>  7 files changed, 1623 insertions(+), 224 deletions(-)
>  create mode 100644 tools/libxl/libxl_usb.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index b417372..08cdb12 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -95,7 +95,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
> libxl_pci.o \
>                       libxl_internal.o libxl_utils.o libxl_uuid.o \
>                       libxl_json.o libxl_aoutils.o libxl_numa.o \
>                       libxl_save_callout.o _libxl_save_msgs_callout.o \
> -                     libxl_qmp.o libxl_event.o libxl_fork.o $(LIBXL_OBJS-y)
> +                     libxl_qmp.o libxl_event.o libxl_fork.o libxl_usb.o 
> $(LIBXL_OBJS-y)

The contents of that file looks Linux specific, so I think you might
have to arrange for it to only be built there and also to provide a
libxl_nousb.c with stubs returning appropriate errors to be used on
other platforms.

Or it may be possible (even better) to refactor the linux specific bits
of libxl_usb.c into libxl_linux.c and leave the common stuff behind.

I thought libxl_pci.c would be a good example of this, but it doesn't
seem to have any conditional stuff, yet I expected it to be Linux
specific. I've no idea how that works :-(. Maybe usb can get away with
it too.

> +int libxl_intf_to_device_usb(libxl_ctx *ctx, uint32_t domid,
> +                            char *intf, libxl_device_usb *usb)
> +                            LIBXL_EXTERNAL_CALLERS_ONLY;

I wasn't sure what an "intf" was on patch #1. hopefully your answer
there will help me understand what this is for!

> diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
> new file mode 100644
> index 0000000..830a846
> --- /dev/null
> +++ b/tools/libxl/libxl_usb.c

Apart from my not yet understanding the interface semantics and the
potential for Linux-specificness mentioned above the actual code here
looks reasonably OK to me. I have smaller and larger comments below
though.

> +static int libxl__device_usbctrl_setdefault(libxl__gc *gc, uint32_t domid,
> +                                            libxl_device_usbctrl *usbctrl)
> +{
[...]
> +    if(!usbctrl->backend_domid)

Missing space before (.


> +static int libxl__usbctrl_add_xenstore(libxl__gc *gc, uint32_t domid,
> +                                       libxl_device_usbctrl *usbctrl)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    flexarray_t *front;
> +    flexarray_t *back;
> +    libxl__device *device;
> +    xs_transaction_t tran;
> +    int rc = 0;
> +
> +    GCNEW(device);
> +    rc = libxl__device_from_usbctrl(gc, domid, usbctrl, device);
> +    if (rc) goto out;
> +
> +    front = flexarray_make(gc, 4, 1);
> +    back = flexarray_make(gc, 12, 1);
> +
> +    flexarray_append(back, "frontend-id");
> +    flexarray_append(back, libxl__sprintf(gc, "%d", domid));

GCSPRINTF would be good for all of these (and in lots of other places
too).

flexarray_append_pair is also nice for adding key+value at the same time
since it makes it easier to see what goes together.

> +retry_transaction:
> +    tran = xs_transaction_start(ctx->xsh);

Please follow the design pattern in e.g. libxl__device_vtpm_add or
device_disk_add and use libxl__xs_transaction_start/commit/abort here
inside a for (;;).

> +static int libxl__device_usbctrl_add(libxl__gc *gc, uint32_t domid,
> +                                     libxl_device_usbctrl *usbctrl)
> +{
> [...]
> +    if (libxl__usbctrl_add_xenstore(gc, domid, usbctrl) < 0){

Space before { please.

> +static int
> +libxl__device_usbctrl_remove_common(libxl_ctx *ctx, uint32_t domid,
> +                                    libxl_device_usbctrl *usbctrl,
> +                                    const libxl_asyncop_how *ao_how,
> +                                    int force)
> +{
> [...]
> +    for (i = 0; i < numusb; i++) {
> +        if (libxl__device_usb_remove_common(gc, domid, &usbs[i], 0)) {
> +            fprintf(stderr, "libxl_device_usb_remove failed.\n");

Use LOG*( please, not fprintf (this is true everywhere in libxl in case
I missed any other).

> +/* usb device functions */
> +
> +/* Following functions are to get assignable usb devices */
> +static int
> +libxl__device_usb_assigned_list(libxl__gc *gc,
> +                                libxl_device_usb **list, int *num)
> +{
> +    char **domlist;
> +    unsigned int nd = 0, i, j;
> +    char *be_path;
> +    libxl_device_usb *usb;
> +
> +    *list = NULL;
> +    *num = 0;
> +
> +    domlist = libxl__xs_directory(gc, XBT_NULL, "/local/domain", &nd);
> +    be_path = libxl__sprintf(gc,"/local/domain/0/backend/vusb");

GCSPRINTF.

Also I notice a hardcoded 0, shouldn't that be backend_domid somehow?
I've seen a few /0/ hardcoded here and there in this patch, which if not
backend_domid perhaps ought to at least be LIBXL_TOOLSTACK_DOMID.

If not then is it necessary to dup the string, can't it just be a const
string literal?

> +static bool is_usb_assignable(libxl__gc *gc, char *intf)
> +{
> +    char buf[5];
> +
> +    if (get_usb_bDeviceClass(gc, intf, buf) < 0)
> +        return false;
> +
> +    if (strcmp(buf, USBHUB_CLASS_CODE))
> +        return false;


OOI are hubs inherently unassignable, or is that a short coming of the
current driver code?

> +/* get all usb devices of the domain */
> +static libxl_device_usb *
> +libxl_device_usb_list_all(libxl__gc *gc, uint32_t domid, int *num)

Should be in libxl__ namespace, or since it is static you could omit the
namespacing completely if you prefer.

> +/* xenstore usb data */
> +static int libxl__device_usb_add_xenstore(libxl__gc *gc, uint32_t domid,
> +                                          libxl_device_usb *usb)
> +{
> +    libxl_ctx *ctx = CTX;

FYI although it's not required, you can just use CTX in the code if you
prefer.

> [...]
> +    be_path = libxl__sprintf(gc, "%s/port/%d", be_path, usb->port);
> +    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Adding new usb device to xenstore");

The LOG*( macros will help shorten this line.

> +    path = libxl__sprintf(gc, "cat "SYSFS_USB_DEVS_PATH"/%s/manufacturer", 
> intf);

Whoah, what now?

What you want here is to open the fd and use read on it. We may even
have existing helpers for doing so. Certainly using popen on a string
starting with cat isn't what is wanted (at least not without a big and
convincing comment explaining why this should be needed).

I see a bunch of this in this area.

> +int libxl_device_usb_getinfo(libxl_ctx *ctx, char *intf, libxl_usbinfo 
> *usbinfo)
> +{
> +    GC_INIT(ctx);
> +    char buf[512];
> +
> +    if (!get_usb_devnum(gc, intf, buf) )

In consistent spacing.

> +        usbinfo->devnum = atoi(buf);
> +
> +    if ( !get_usb_busnum(gc, intf, buf))
> +        usbinfo->bus = atoi(buf);
> +
> +    if (!get_usb_idVendor(gc, intf, buf) )
> +        usbinfo->idVendor = atoi(buf);
> +
> +    if (!get_usb_idProduct(gc, intf, buf) )
> +        usbinfo->idProduct  = atoi(buf);
> +
> +    if (!get_usb_manufacturer(gc, intf, buf) )
> +        usbinfo->manuf = strdup(buf);

libxl_strdup with NOGC to get correct error handling please.

> +
> +    if (!get_usb_product(gc, intf, buf) )
> +        usbinfo->prod = strdup(buf);
> +
> +    GC_FREE;
> +    return 0;
> +}
> +


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.