On Fri, 28 May 2004, Greg KH wrote: > I'm holding off on the kill_urb() patch for 2.6.7. I like the idea, and > will reconsider it for 2.6.8. Sound ok?
Okay. > Everything else I have from you I've either applied, or lost in the mess > somewhere. If I have lost anything else, please feel free to resend it. 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'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. Alan Stern ------------------------------------------------------- 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
