public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, vserver@list.linux-vserver.org,
	Herbert Poetzl <herbert@13thfloor.at>,
	"Serge E. Hallyn" <serue@us.ibm.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Dave Hansen <haveblue@us.ibm.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Suleiman Souhlal <ssouhlal@FreeBSD.org>,
	Hubertus Franke <frankeh@watson.ibm.com>,
	Cedric Le Goater <clg@fr.ibm.com>,
	Kyle Moffett <mrmacman_g4@mac.com>
Subject: Re: [PATCH 1/5] pid: Implement task references.
Date: Sun, 29 Jan 2006 20:51:53 -0800	[thread overview]
Message-ID: <20060130045153.GC13244@kroah.com> (raw)
In-Reply-To: <m1mzhe7l2c.fsf@ebiederm.dsl.xmission.com>

On Sun, Jan 29, 2006 at 02:58:51PM -0700, Eric W. Biederman wrote:
> Greg KH <greg@kroah.com> writes:
> 
> > On Sun, Jan 29, 2006 at 12:22:34AM -0700, Eric W. Biederman wrote:
> >> +struct task_ref
> >> +{
> >> +	atomic_t count;
> >
> > Please use a struct kref here, instead of your own atomic_t, as that's
> > why it is in the kernel :)
> >
> >> +	enum pid_type type;
> >> +	struct task_struct *task;
> >> +};
> >
> > thanks,
> 
> I would rather not. Whenever I look at struct kref it seems to be an over
> abstraction, and as such I find it confusing to work with.  I know
> whenever I look at the sysfs code I have to actively remind myself
> that the kref in the structure is not a pointer to a kref.
> 
> What does the kref abstraction buy?  How does it simplify things?
> We already have equivalent functions in atomic_t on which it is built.

It ensures that you get the logic of the reference counting correctly.
It forces you to do the logic of the get and put and release properly.

To roughly quote Andrew Morton, "When I see a kref, I know it is used
properly, otherwise I am forced to read through the code to see if the
author got the reference counting logic correct."

It costs _nothing_ to use it, and let's everyone know you got the logic
correct.

So don't feel it is a "abstraction", it's a helper for both the author
(who doesn't have to get the atomic_t calls correct), and for everyone
else who has to read the code.

thanks,

greg k-h

  reply	other threads:[~2006-01-30  4:55 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-29  7:19 [RFC][PATCH 0/5] Task references Eric W. Biederman
2006-01-29  7:22 ` [PATCH 1/5] pid: Implement task references Eric W. Biederman
2006-01-29  7:24   ` [PATCH 2/5] pid: Add macros for interating through tasks by type Eric W. Biederman
2006-01-29  7:28     ` [PATCH 3/5] pid: Implement kill_tref Eric W. Biederman
2006-01-29  7:33       ` [PATCH 4/5] vt: Update spawnpid to use a task_ref Eric W. Biederman
2006-01-29  7:35         ` [PATCH 5/5] file: Modify struct fown_struct to contain a tref Eric W. Biederman
2006-01-29  8:43           ` Suleiman Souhlal
2006-01-29  9:18             ` Eric W. Biederman
2006-01-30 10:51         ` [PATCH 4/5] vt: Update spawnpid to use a task_ref Pavel Machek
2006-01-30 20:39           ` Eric W. Biederman
2006-01-30 21:05             ` Pavel Machek
2006-01-30 21:15               ` Eric W. Biederman
2006-01-29  8:46   ` [PATCH 1/5] pid: Implement task references Suleiman Souhlal
2006-01-29 19:05   ` Greg KH
2006-01-29 21:58     ` Eric W. Biederman
2006-01-30  4:51       ` Greg KH [this message]
2006-01-30  5:19         ` Eric Dumazet
2006-01-30  5:35           ` Kyle Moffett
2006-01-30  5:46             ` Eric Dumazet
2006-01-30  6:46               ` Kyle Moffett
2006-01-30 18:43           ` Greg KH
2006-01-30 19:58             ` Eric Dumazet
2006-01-30 20:45               ` Eric W. Biederman
2006-01-30 21:32                 ` Eric Dumazet
2006-01-30 21:51                   ` Eric W. Biederman
2006-01-30 20:13         ` Eric W. Biederman
2006-01-31  6:58           ` Greg KH
2006-01-31 16:04             ` Eric W. Biederman
2006-01-29  8:05 ` [RFC][PATCH 0/5] Task references Kyle Moffett
2006-02-06  8:09 ` Eric W. Biederman
2006-02-06 14:36   ` Serge E. Hallyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060130045153.GC13244@kroah.com \
    --to=greg@kroah.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=clg@fr.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=frankeh@watson.ibm.com \
    --cc=haveblue@us.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrmacman_g4@mac.com \
    --cc=serue@us.ibm.com \
    --cc=ssouhlal@FreeBSD.org \
    --cc=vserver@list.linux-vserver.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox