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'. 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. 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. > 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. :-) // 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
