This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] bug in usbback

> >
> > So maybe "port-N=S" would become "port-N=GGS", where S is the
> > '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.

> Furthermore, usbfront only emulates the roothub ports' virtual status
> by the value of port-N's speed, and, even if the counter value is
> 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.

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


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>