Re: [patch] Add kref_read and kref_put_last primitives

[Greg KH]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/