All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Abbott <abbotti@mev.co.uk>
To: Rob Landley <rob@landley.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Corrections to Documentation/rbtree.txt
Date: Wed, 26 Mar 2008 14:09:35 +0000	[thread overview]
Message-ID: <47EA591F.9020507@mev.co.uk> (raw)
In-Reply-To: <200803251324.08769.rob@landley.net>

On 25/03/08 18:24, Rob Landley wrote:
> On Tuesday 25 March 2008 06:02:22 Ian Abbott wrote:
>> On 20/03/08 18:39, Rob Landley wrote:
>>> On Thursday 20 March 2008 10:29:57 Ian Abbott wrote:
>>>> From: Ian Abbott <abbotti@mev.co.uk>
>>>>
>>>> The description of the rb_entry() macro in Documentation/rbtree.txt
>>>> seems incorrect. This patch improves it (hopefully).  Also I changed the
>>>> example code to call the previous 'my_search()' example instead of an
>>>> undefined 'mysearch()'.
>>> I have no objection to the patch (and the my_search thing seems like an
>>> obvious typo), but is there a reason to prefer rb_entry() rather than
>>> container_of()?  If so, the rationale might be a good thing to add to the
>>> documentation...
>> I don't know the rationale, but all the code I can see uses rb_entry()
>> and not container_of().
> 
> Except container_of() works, which is a nice thing to know, and it already 
> mentions rb_entry() as another way to do it.  If someone could explain _why_ 
> to use one over the other, that would be a good thing to add.

Let's see if Andrea Arcangeli can still remember the rationale from 9 
years ago! :-)

container_of() works just as well, but _none_ of the existing code in 
the kernel uses it to access the container of the struct rb_node; they 
all use rb_entry(), including the example code in include/linux/rbtree.h.

> Again, I don't care much either way, I just want to know what the point is of 
> choosing one over the other that makes changing what's there worth bothering 
> with.  You're changing the documentation to hide the fact that rb_entry() is 
> basically another name for container_of(), and this is supposed to be an 
> improvement?

Personally I have no preference for rb_entry() over container_of(), but 
as all the code in the kernel uses rb_entry() it seems better if the 
examples in the documentation use it too.

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti@mev.co.uk>        )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587         )=-

  reply	other threads:[~2008-03-26 14:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-20 15:29 [PATCH] Corrections to Documentation/rbtree.txt Ian Abbott
2008-03-20 18:39 ` Rob Landley
2008-03-25 11:02   ` Ian Abbott
2008-03-25 18:24     ` Rob Landley
2008-03-26 14:09       ` Ian Abbott [this message]
2008-03-25 11:29   ` Ian Abbott

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=47EA591F.9020507@mev.co.uk \
    --to=abbotti@mev.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob@landley.net \
    /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.