On Fri, May 28, 2004 at 05:35:27PM -0400, Alan Stern wrote: > Hmm... There were two more patches which I _thought_ had been sent out, > but they don't seem to be in the archives. I'll send them again.
I got them after I sent the last round off to Linus. They are now in my queue for the next round of USB patches to send off, thanks. > > > I'm not entirely pleased with the decision to use an 8-bit counter to keep > > > track of URB usage, since it requires an additional spinlock during the > > > submit_urb and giveback_urb paths. Those could be eliminated if the > > > counter were converted to an atomic_t -- an easy change to make if you > > > think it would be a significant improvement. > > > > I thought we objected to an atomic_t for some reason, but can't remember > > it now... Anyone else? > > Oliver objected because he thought a single bit could do the job. But it > can't, since the counter needs to be able to go up to 2. (The counter is > still equal to 1 while the completion handler runs, and if the handler > resubmits then the counter has to be set to 2.) > > As far as I can recall, the only other objection was to adding extra > fields to struct urb. Dedicating a 4-byte (or more on some architectures) > atomic_t to a counter that is not likely ever to go above 2 might seem > excessive. But the kernel generally seems to favor these time-over-space > tradeoffs. Ok, that sounds reasonable to me. greg k-h ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
