|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |