Re: bug in usbback

[Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>]

Hi,

James Harper wrote:
>>> So maybe "port-N=S" would become "port-N=GGS", where S is the
> current
>>> 'speed' value, and "GG" is a change counter. As an example:
>>>
>>> 1. port-1=000
>>> 2. <hot plug>
>>> 3. port-1=013
>>> 4. <hot unplug>
>>> 5. port-1=020
>>> 6. <hot plug>
>>> 7. port-1=033
>> I don't think it's a good idea.
>>
>> If disconnection happened, the urb transfer is sure to make an error,
>> and usbfront can detect this error without counter.
> 
> Is it a good idea for the usb device driver running in the frontend to
> detect an unplug->replug event by getting error codes? It could report a
> device failure in that case rather than figuring out that the device has
> been unplugged and replugged.

USB device driver (aka function driver) detects plug/unplug event by
probe/disconnect callbacks. These callbacks and URB transfer error
callback are different.

Disconnection causes the transfer error, or disconnection is detected
and the transfer is canceled. Normally, after canceling the transfer,
the device is re-initialized (if the device is still present).

In any case, it might be another problem that reports the disconnection
event as an error.

>> Furthermore, usbfront only emulates the roothub ports' virtual status
>> by the value of port-N's speed, and, even if the counter value is
> wrong,
>> this value cannot be associated to the rootport's status.
> 
> The last digit of the counter still represents the port virtual status.
> Only the first two digits increment. As per my previous email, the
> format of the port-N xenstore entry would become 'GGS' where GG is the
> counter value and 'S' is the status, as it is now.

I mean "roothub ports' virtual status" as port status that is emulated
in usbfront roothub part. How do you associate the error of the counter
to wPortChange bit field?
  (See struct rhport_status in usbfront.h and usbfront_hub.c)

>> As I mentioned, if notifications by xenbus has the problem, I prefer
>> using RING.
>>
> 
> The problem with the ring method is that there has to be an outstanding
> ring request sent by the frontend in order for the backend to be able to
> notify the frontend. I think that would add unnecessary overhead.
> 

I believe the method of no "reconfiguring mismatch" happening is better
than correcting the mismatch. It's necessary overhead.

Regards,
Noboru