Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-31 Thread Franck Bui-Huu
Sam Bishop wrote: > On Wednesday 30 August 2006 3:40 am, Franck Bui-Huu wrote: >> This patch also fixes a bug in usb_device_poll() at the same time. >> Previous code always raised POLLIN bit although no event happened >> on the bus. > > I believe this is expected behavior. I mentioned it in the p

Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-30 Thread Sam Bishop
On Wednesday 30 August 2006 3:40 am, Franck Bui-Huu wrote: > This patch also fixes a bug in usb_device_poll() at the same time. > Previous code always raised POLLIN bit although no event happened > on the bus. I believe this is expected behavior. I mentioned it in the patch I submitted and no on

Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-30 Thread Franck Bui-Huu
David Brownell wrote: > On Tuesday 29 August 2006 9:35 am, Sam Bishop wrote: >> On Tue, Aug 29, 2006 at 08:30:45AM -0700, David Brownell wrote: >>> On Monday 28 August 2006 1:27 pm, Sam Bishop wrote: + /* To see what's changed, compare the file's previous and current + contents or sc

Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-29 Thread Sam Bishop
On Tuesday 29 August 2006 10:51 am, David Brownell wrote: > Erm, what I meant was removing mention of the error prone "compare" case. > If you're going to mention it, highlight that it's got internal races; > otherwise, don't mention it. I believe my patch is now what I originally intended: a litt

Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-29 Thread David Brownell
On Tuesday 29 August 2006 9:35 am, Sam Bishop wrote: > On Tue, Aug 29, 2006 at 08:30:45AM -0700, David Brownell wrote: > > On Monday 28 August 2006 1:27 pm, Sam Bishop wrote: > > > + /* To see what's changed, compare the file's previous and current > > > +contents or scan the filesystem. (Scan

Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-29 Thread Sam Bishop
On Tue, Aug 29, 2006 at 08:30:45AM -0700, David Brownell wrote: > On Monday 28 August 2006 1:27 pm, Sam Bishop wrote: > > + /* To see what's changed, compare the file's previous and current > > + contents or scan the filesystem. (Scanning is more precise.) */ > > Rather than "more precise"

Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-29 Thread David Brownell
On Monday 28 August 2006 1:27 pm, Sam Bishop wrote: > On Thu, Aug 24, 2006 at 03:04:33PM -0700, David Brownell wrote: > > Just revert to the previous language ... if you want, emphasize that > > the scanning is to figure out precisely what changed. > > How's this? (I've made a few other small cha

Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-28 Thread Sam Bishop
On Thu, Aug 24, 2006 at 03:04:33PM -0700, David Brownell wrote: > Just revert to the previous language ... if you want, emphasize that > the scanning is to figure out precisely what changed. How's this? (I've made a few other small changes too.) A little more detail on how and when to poll() /

Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-24 Thread David Brownell
On Thursday 24 August 2006 1:09 pm, Sam Bishop wrote: > I also removed the reference to "scanning the filesystem" as a way to > detect hotplug events. I can't think of any reason why someone would > want to do it that way. The reference was about seeing what changed, so that e.g. you can display

Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-24 Thread David Brownell
On Thursday 24 August 2006 2:47 pm, Sam Bishop wrote: > On Thursday 24 August 2006 2:49 pm, David Brownell wrote: > > On Thursday 24 August 2006 1:09 pm, Sam Bishop wrote: > > > I also removed the reference to "scanning the filesystem" as a way to > > > detect hotplug events. I can't think of any

Re: [linux-usb-devel] [PATCH] another usb.tmpl change

2006-08-24 Thread Sam Bishop
On Thursday 24 August 2006 2:49 pm, David Brownell wrote: > On Thursday 24 August 2006 1:09 pm, Sam Bishop wrote: > > I also removed the reference to "scanning the filesystem" as a way to > > detect hotplug events. I can't think of any reason why someone would > > want to do it that way. > > The r