[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

 


Rackspace

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