Message-Id: <200503022130.j22LU6H02463@blake.inputplus.co.uk>
To: Corey Minyard <cminyard@mvista.com>
cc: Greg KH <greg@kroah.com>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: Documentation for krefs 
In-Reply-To: <422617F1.2080404@mvista.com> 
Date: Wed, 02 Mar 2005 21:30:06 +0000
From: Ralph Corderoy <ralph@inputplus.co.uk>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1385
Lines: 60


Hi Corey,

> Here is the documentation for krefs, with the kref_checked stuff
> removed and a few other things cleaned up.

Great, more documentation.  :-)  A few minor points...

> +To use a kref, add a one to your data structures like:

s/a one/one/

> +You must initialize the kref after you allocate it.  To do this, call
> +kref init as so:

s/kref init/kref_init/

> +Once you have a refcount, you must follow the following rules:

s/refcount/initialised kref/

> +	if (task == ERR_PTR(-ENOMEM)) {
> +		rv = -ENOMEM;
> +	        kref_put(&data->refcount);

s/)/, data_release)/

> +		goto out;
> +	}
> +
> +	.
> +	. do stuff with data here
> +	.
> + out:
> +	kref_put(data, data_release);

s/data/\&data->refcount/ ?

> +	return rv;
> +}
> +
> +This way, it doesn't matter what order the two threads handle the
> +data, the put handles knowing when the data is free and releasing it.

s/put/kref_put()/

> +The kref_get() does not require a lock, since we already have a valid
> +pointer that we own a refcount for.  The put needs no lock because
> +nothing tries to get the data without already holding a pointer.

Cheers,


Ralph.

-
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/