[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:27 PM, in message <CAFLBxZaf5fJOJ6dgBCMsm4kDa5_XihOWShqhOS1zwWXJU9beXw@xxxxxxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote: > On Thu, Mar 3, 2016 at 2:59 AM, Chun Yan Liu <cyliu@xxxxxxxx> wrote: >>>>> On 3/3/2016 at 02:46 AM, in message <56D7350F.7010000@xxxxxxxxxx>, George > > Dunlap <george.dunlap@xxxxxxxxxx> wrote: > >> Sorry, just looked through the rest of the series, and there's one more > >> thing. > >> > >> Neither here nor in the man page do we explain what to do if something > >> goes wrong with the detach. I think the best thing to do is probably to > >> make the logged error messages more helpful. > >> > >> What about something like this: > >> > >> * On failure to unbind: "Error removing device from guest. Try running > >> usbdev-detach again." > >> > >> * On failure to rebind: "USB device removed from guest, but couldn't > >> re-bind to domain 0. Try removing and re-inserting the USB device or > >> reloading the driver modules." > > Here, user could first try 'echo xxx > sysfs_driver_path/bind", so maybe: > > "Try binding USB device to original driver by echoing the device to > > [driver_path]/bind, or removing and re-inserting the USB device, or > > reloading the driver modules." > > Yes, I had thought about the idea of giving the user specific commands > to retry. The question is how much we can expect the user to do to > recover the state. At some point "reloading the driver module" was > seen as something reasonable for a reasonably advanced user, while > "messing around with sysfs" was seen to be something too technical. > But as you say, giving them the exact command to cut-and-paste might > be somewhat more reasonable. > > I'm still inclined to say that we should just stick with module > reloading and removing and re-inserting the device, but I wouldn't > insist on it. I see. Just use what you suggested. Will update and repost. Thanks, Chunyan > > If we do print this kind of help message, then we should make sure to > print a more complete message that includes cut-and-paste commands for > *all* remaining unbound interfaces. > > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |