All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] struct list_node
Date: Mon, 11 Jun 2007 10:02:17 +1000	[thread overview]
Message-ID: <1181520137.16428.69.camel@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.0.98.0706101013420.20321@woody.linux-foundation.org>

On Sun, 2007-06-10 at 10:20 -0700, Linus Torvalds wrote:
> 
> On Sun, 10 Jun 2007, Rusty Russell wrote:
> >
> > The current list.h has the same type for list elements and list heads
> > even though most code and coders treat them as distinct.
> 
> I think the old list.h is technically superior to yours.
> 
> Exactly *because* nodes and heads are interchangeable.
> 
> In fact, you are incorrect that "most code" treat them as distinct. Most 
> code that uses list.h in fact uses it as a list of entries, often without 
> any head at all (and each *entry* is a point of removal), because the way 
> to actually *find* the structure that contains the lists is separate from 
> the lists themselves.

Sorry, do you really believe a ring is "often" the case?  It's not
entirely trivial to audit, but I can do a random sample of 100
list_heads.

The list iterators reinforce the "standalone head" model (ie. it's not
called list_for_each_other_entry), and they're pretty popular.

> The Linux kernel list.h is _better_ than most stupid list implementations 
> that think that a head node is different from the list node. Exactly 
> because it very naturally supports the notion of "this structure exists in 
> a 'ring of entries'" where each node is 100% equivalent to any other node, 
> and there _is_ no head.

I agree it's a wonderful feature, but you talk about "no head" but
they're all called "list_head"?  In my version, they'd all be list_node,
and you can trivially treat it as a head with ->h.

It's a little more work for rings, but it's more explicit and gives us
type checking on the common case.

Thanks for your consideration,
Rusty.


  parent reply	other threads:[~2007-06-11  0:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-10  5:11 [PATCH RFC] struct list_node Rusty Russell
2007-06-10 17:13 ` Randy Dunlap
2007-06-10 17:20 ` Linus Torvalds
2007-06-10 20:19   ` Linus Torvalds
2007-06-11  0:08     ` Rusty Russell
2007-06-11  0:02   ` Rusty Russell [this message]
2007-06-14 10:03 ` Jan Blunck

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=1181520137.16428.69.camel@localhost.localdomain \
    --to=rusty@rustcorp.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 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.