All of lore.kernel.org
 help / color / mirror / Atom feed
From: Louis Rilling <Louis.Rilling@kerlabs.com>
To: Joel Becker <Joel.Becker@oracle.com>
Cc: linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com,
	ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [RFC] configfs: Pin configfs subsystems	separately from new config_items.
Date: Mon, 23 Jun 2008 17:44:57 +0200	[thread overview]
Message-ID: <20080623154457.GW30804@localhost> (raw)
In-Reply-To: <20080620223614.GD21416@mail.oracle.com>

On Fri, Jun 20, 2008 at 03:36:14PM -0700, Joel Becker wrote:
> On Fri, Jun 20, 2008 at 02:46:44PM +0200, Louis Rilling wrote:
> > But keeping this last config_item_put() prevents the simplification that I'm
> > defending. And I think that the simplification is worth moving this
> > config_item_put() before client_drop_item().
> 
> 	I guess I'm not seeing what's simpler.  Four lines of
> try_module_get() aren't very complex, really.  Conversely, having some
> functions that *don't* do config_item_get_item() is weird.  Not invalid,
> just harder to read.

config_item_get_item() followed by config_item_put(), with a comment on why this
is correct, was my suggestion, not avoiding to call config_item_get_item().

> 	Let's put it on the shelf.  What I have with this patch is
> really no different in effective behavior.

I'm completely ok with your patch. I just thought that this was the occasion to
cleanup module pinning stuff.

Would you consider the last following argument?

Consider a very simple subsystem, implemented by a single module, that does
absolutely no config_item_get(). Currently, this module must provide a release()
operation for all user-created config_items, because the last reference is
dropped by configfs, right after dropping the item. With my simplification, the
module effectively drops the last reference in ->drop_item(), and could rely on
that to make the code simpler like below:

make_item()
	new_item = kmalloc();
	config_item_init_type_long_name();
	return new_item;

drop_item(item)
	config_item_put(item);
	kfree(item);

No need for a release() operation in that simple case, and one may find such
code more readable thanks to its symmetry.

Looking at some in-tree code, netconsole would be a candidate for such code
simplification. Indeed, netconsole does not look like needing config_item_get(),
because the target_list_lock already provides the necessary protection.

That said, thanks for the discussion, and for not forgetting the idea :)

Louis

-- 
Dr Louis Rilling			Kerlabs
Skype: louis.rilling			Batiment Germanium
Phone: (+33|0) 6 80 89 08 23		80 avenue des Buttes de Coesmes
http://www.kerlabs.com/			35700 Rennes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20080623/8540dbea/attachment.bin 

WARNING: multiple messages have this Message-ID (diff)
From: Louis Rilling <Louis.Rilling@kerlabs.com>
To: Joel Becker <Joel.Becker@oracle.com>
Cc: linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com,
	ocfs2-devel@oss.oracle.com
Subject: Re: [Ocfs2-devel] [RFC] configfs: Pin configfs subsystems separately from new config_items.
Date: Mon, 23 Jun 2008 17:44:57 +0200	[thread overview]
Message-ID: <20080623154457.GW30804@localhost> (raw)
In-Reply-To: <20080620223614.GD21416@mail.oracle.com>

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]

On Fri, Jun 20, 2008 at 03:36:14PM -0700, Joel Becker wrote:
> On Fri, Jun 20, 2008 at 02:46:44PM +0200, Louis Rilling wrote:
> > But keeping this last config_item_put() prevents the simplification that I'm
> > defending. And I think that the simplification is worth moving this
> > config_item_put() before client_drop_item().
> 
> 	I guess I'm not seeing what's simpler.  Four lines of
> try_module_get() aren't very complex, really.  Conversely, having some
> functions that *don't* do config_item_get_item() is weird.  Not invalid,
> just harder to read.

config_item_get_item() followed by config_item_put(), with a comment on why this
is correct, was my suggestion, not avoiding to call config_item_get_item().

> 	Let's put it on the shelf.  What I have with this patch is
> really no different in effective behavior.

I'm completely ok with your patch. I just thought that this was the occasion to
cleanup module pinning stuff.

Would you consider the last following argument?

Consider a very simple subsystem, implemented by a single module, that does
absolutely no config_item_get(). Currently, this module must provide a release()
operation for all user-created config_items, because the last reference is
dropped by configfs, right after dropping the item. With my simplification, the
module effectively drops the last reference in ->drop_item(), and could rely on
that to make the code simpler like below:

make_item()
	new_item = kmalloc();
	config_item_init_type_long_name();
	return new_item;

drop_item(item)
	config_item_put(item);
	kfree(item);

No need for a release() operation in that simple case, and one may find such
code more readable thanks to its symmetry.

Looking at some in-tree code, netconsole would be a candidate for such code
simplification. Indeed, netconsole does not look like needing config_item_get(),
because the target_list_lock already provides the necessary protection.

That said, thanks for the discussion, and for not forgetting the idea :)

Louis

-- 
Dr Louis Rilling			Kerlabs
Skype: louis.rilling			Batiment Germanium
Phone: (+33|0) 6 80 89 08 23		80 avenue des Buttes de Coesmes
http://www.kerlabs.com/			35700 Rennes

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2008-06-23 15:44 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-17 22:41 [Cluster-devel] [RFC] configfs: Pin configfs subsystems separately from new config_items Joel Becker
2008-06-17 22:41 ` Joel Becker
2008-06-17 22:41 ` [Ocfs2-devel] " Joel Becker
2008-06-18 12:31 ` Louis Rilling
2008-06-18 12:31   ` Louis Rilling
2008-06-18 16:12   ` [Cluster-devel] " Joel Becker
2008-06-18 16:12     ` Joel Becker
2008-06-18 16:12     ` Joel Becker
2008-06-18 16:51     ` Louis Rilling
2008-06-18 16:51       ` Louis Rilling
2008-06-18 20:07       ` [Cluster-devel] " Joel Becker
2008-06-18 20:07         ` Joel Becker
2008-06-18 20:07         ` [Ocfs2-devel] " Joel Becker
2008-06-19 11:13         ` Louis Rilling
2008-06-19 11:13           ` Louis Rilling
2008-06-19 22:07           ` [Cluster-devel] " Joel Becker
2008-06-19 22:07             ` Joel Becker
2008-06-19 22:07             ` Joel Becker
2008-06-20 12:46             ` Louis Rilling
2008-06-20 12:46               ` Louis Rilling
2008-06-20 22:36               ` [Cluster-devel] " Joel Becker
2008-06-20 22:36                 ` Joel Becker
2008-06-20 22:36                 ` Joel Becker
2008-06-23 15:44                 ` Louis Rilling [this message]
2008-06-23 15:44                   ` Louis Rilling
2008-06-23 19:10                   ` [Cluster-devel] " Joel Becker
2008-06-23 19:10                     ` Joel Becker
2008-06-23 19:10                     ` Joel Becker
2008-06-24  5:04                     ` Louis Rilling
2008-06-24  5:04                       ` Louis Rilling
2008-06-24 17:03                       ` [Cluster-devel] " Joel Becker
2008-06-24 17:03                         ` Joel Becker
2008-06-24 17:03                         ` [Ocfs2-devel] " Joel Becker

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=20080623154457.GW30804@localhost \
    --to=louis.rilling@kerlabs.com \
    --cc=Joel.Becker@oracle.com \
    --cc=cluster-devel@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ocfs2-devel@oss.oracle.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.