On Thursday 28 September 2006 4:50 am, Marcus Comstedt wrote: > > David Brownell <[EMAIL PROTECTED]> writes: > > > The use of kref was a simplification ... adopting an idiom that was > > used in many other places in the kernel. You're right that there > > was no need for its "atomic" aspect, since those refcounts should > > always have been protected by the driver spinlock. > > Ok, then the most simple solution should work, which as you point out > is good from a complexity fighting POV. > > > > I like the idea of keeping to that idiom. How about just defining > > a non-atomic version of kref, for use in cases where atomic ops are > > not appropriate? Seems to me that should be fully inlinable. > > I'm not so sure it's a good idea to keep calling it a "kref" if its > semantics differs from other krefs'.
Well, a "struct ehci_kref" would be hard to confuse. Semantics would cleary be EHCI-specific. ;) > If the idiom is to use a kref > for atomic refcounting, then using a kref for non-atomic refcounting > might be considered violating the idiom, which is worse than not using > it at all (since the point of the idiom is to create understanding > through recognition, but in this case it might instead become > misunderstanding through recognition). Also I'd argue that since the > implementation of the refcounting is completely encapsulated by the > qh_get() and qh_put() functions, the need to stick to idioms is > slightly less than elsewhere; the code is local and simple enough to > be easily comprehensable anyway. Could be. I think Greg is the person who changed EHCI over to use kref, from local refcounting, mostly as an example. :) > Of course, if there is a wide demand for non-atomic refcounters in > DMAable memory, it might make sense to create a different kind of kref > (thus creating a new idiom), but from what I've seen this is not a > common practice. Not common, no. > > I see you have prioritized these proposals so that each successive > > one makes me less and less comfortable ... ;) > > Actually, I prioritized the proposals so that the ones _I_ was most > comfortable with was presented first. I'm glad we agree about the > prioritization. :-) :) - Dave > // Marcus > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
