Messages in this thread | | | Date | Mon, 2 Aug 2004 23:51:30 -0700 | From | Greg KH <> | Subject | Re: [patch] Add kref_read and kref_put_last primitives |
| |
On Tue, Aug 03, 2004 at 11:12:18AM +0530, Dipankar Sarma wrote: > On Mon, Aug 02, 2004 at 01:08:49PM -0700, Greg KH wrote: > > On Mon, Jul 26, 2004 at 05:31:51PM +0100, Christoph Hellwig wrote: > > > Why don't you simply use an atomic_t if that's what you seem to > > > want? > > > > Exactly. In cases like this, where the user, for some reason, wants to > > know the state of the reference count, they should not use a struct > > kref. I'm not going to add these functions to the kref api, sorry. > > > > Really, there is no need to use kref in where Ravikiran is using > them (VFS) under the current circumstances. However, if lock-free > lookup using RCU is to be used, Ravikiran needs to use an abstracted reference > counter API. This is to optimally support platforms with and without > cmpxchg. kref is the standard reference counter API at the moment and > that is where it made sense to add the abstracted lockfree reference counter > support.
Hm, I still don't agree :)
> So, kref_read() as it is would look weird. But if we consider merging > the rest of the kref APIs (lock-free extensions) in future, then the > entire set including kref_read() would make sense.
No, even with rcu versions, I don't see the need for this in the api.
Sure, for this specific implementation of a atomic_t, it is useful, as the value is checked. But that means that you might just want to use an atomic_t, as it doesn't fit the model of a struct kref at all (something where you don't touch the reference count directly at all.)
Becides, I don't think that people are convinced that this code needs to be changed anyway :)
thanks,
greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |