From mboxrd@z Thu Jan 1 00:00:00 1970 From: Noboru Iwamatsu Subject: Re: bug in usbback Date: Tue, 28 Jul 2009 11:41:58 +0900 Message-ID: <4A6E6576.1020109@jp.fujitsu.com> References: <4A6D376D.6000808@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: james.harper@bendigoit.com.au Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Hi, >> Do you think it's good idea that the method for the notification >> of hotplug is switched from xenbus to RING (like pv network's > rx_ring)? > > I like the idea of having the port states in the xenstore. It is a low > speed and (mostly) relatively infrequently changing thing so I think > keeping it in xenstore is appropriate. > > I think the problem could be solved by simply including a port change > counter for each port, either as part of the existing port-N value or as > an additional 'port-N-generation' field. The backend would just > increment that every time there is a plug or unplug event, and the > frontend could compare the value to what it was last time to see if the > port had changed. > > > 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. > 3. port-1=013 > 4. > 5. port-1=020 > 6. > 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. 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. As I mentioned, if notifications by xenbus has the problem, I prefer using RING. Regards, Noboru