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

Re: [Xen-devel] [PATCH V15 4/6] libxl: add pvusb API




>>> On 3/3/2016 at 05:20 PM, in message
<CAFLBxZaOYB0PSxxJi_mF3G6yie80oh2X_O3tJahTH1XJMJjEkA@xxxxxxxxxxxxxx>, George
Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote: 
> On Thu, Mar 3, 2016 at 3:11 AM, Chun Yan Liu <cyliu@xxxxxxxx> wrote: 
>>>>> On 3/3/2016 at 02:32 AM, in message <56D731B1.60009@xxxxxxxxxx>, George 
>>>>> Dunlap 
> > <george.dunlap@xxxxxxxxxx> wrote: 
> >> On 01/03/16 08:09, Chunyan Liu wrote: 
> >> > +static int usbdev_rebind(libxl__gc *gc, const char *busid) 
> >> > +{ 
> >> > +    char **intfs = NULL; 
> >> > +    char *usbdev_encode = NULL; 
> >> > +    char *path = NULL; 
> >> > +    int i, num = 0; 
> >> > +    int rc; 
> >> > + 
> >> > +    rc = usbdev_get_all_interfaces(gc, busid, &intfs, &num); 
> >> > +    if (rc) goto out; 
> >> > + 
> >> > +    usbdev_encode = usb_interface_xenstore_encode(gc, busid); 
> >> > + 
> >> > +    for (i = 0; i < num; i++) { 
> >> > +        char *intf = intfs[i]; 
> >> > +        char *usbintf_encode = NULL; 
> >> > +        const char *drvpath; 
> >> > + 
> >> > +        /* rebind USB interface to its originial driver */ 
> >> > +        usbintf_encode = usb_interface_xenstore_encode(gc, intf); 
> >> > +        path = GCSPRINTF(USBBACK_INFO_PATH "/%s/%s/driver_path", 
> >> > +                         usbdev_encode, usbintf_encode); 
> >> > +        rc = libxl__xs_read_checked(gc, XBT_NULL, path, &drvpath); 
> >> > +        if (rc) goto out; 
> >> > + 
> >> > +        if (drvpath) { 
> >> > +            rc = bind_usbintf(gc, intf, drvpath); 
> >> > +            if (rc) { 
> >> > +                LOGE(ERROR, "Couldn't rebind %s to %s", intf, drvpath); 
> >> > +                goto out; 
> >> > +            } 
> >> > +        } 
> >> > +    } 
> >> > + 
> >> > +    path = GCSPRINTF(USBBACK_INFO_PATH "/%s", usbdev_encode); 
> >> > +    rc = libxl__xs_rm_checked(gc, XBT_NULL, path); 
> >> > + 
> >> > +out: 
> >> 
> >> So it looks like if one of the re-binds fails, then it stops where it is 
> >> and leaves the USBBACK re-bind info in xenstore.  In that case it's not 
> >> clear to me how that information would ever be removed. 
> >> 
> >> I think until such time as we have a command to re-attempt the re-bind, 
> >>  if there's an error in the actual rebind, it should just break out of 
> >> the for loop, and remove the re-bind nodes, and document a way to let 
> >> the user try to clean things up. 
> > 
> > Just according to last time discussion about how to handle the rebind 
> > failure, seems Ian preferred to add a xl command to deal with rebind 
> > in future, based on that need, I think driver_path info should be kept 
> > in xenstore then. Without that need, I agree it's best to remove 
> > xenstore nodes. So, keep or remove? 
>  
> Well when we have such a command, then yes, we'll need to keep the 
> nodes for it to use and delete.  But at the moment, we have no such 
> command, so these nodes will just sit around cluttering up the libxl 
> xenstore space, and nothing will delete them (unless a user manually 
> runs xenstore-rm). 
>  
> So I think for now we should delete them on failure; and at some point 
> later, when someone implements a recovery command, then they should 
> change this code to not delete the xenstore nodes (and also change the 
> log messages to point to that command). 

OK. Got it. Will update.

-  Chunyan

>  
>  -George 
>  
>  


_______________________________________________
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®.