From: Jakob Oestergaard <jakob@unthought.net>
To: Joshua MacDonald <jmacd@namesys.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: type safe lists (was Re: PATCH: type safe(r) list_entry repacement: generic_out_cast)
Date: Wed, 24 Jul 2002 14:22:32 +0200 [thread overview]
Message-ID: <20020724122232.GT11081@unthought.net> (raw)
In-Reply-To: <20020723220745.GD2090@reload.namesys.com>
On Wed, Jul 24, 2002 at 02:07:45AM +0400, Joshua MacDonald wrote:
...
> This may interest you. We have written a type-safe doubly-linked list
> template which is used extensively in reiser4. This is the kind of thing that
> some people like very much and some people hate, so I'll spare you the
> advocacy.
Ok, here's my comments:
*) Using macros like that is ugly as hell, but as I see it it is the
only way to achieve type safety in such generic code. If the ugliness
is confined to one header file, and possibly one .c file containing the
needed instantiations, I would argue that the ugliness is bearable. In
other words, I think your solution is the prettiest one possible.
Since all list routines right now are extremely simple, it's probably ok
to just have it all in a header. If larger routines are added later on,
it may be desirable to create a .c file holding the needed (macro
instantiated) routines. In that case, the following applies:
*) I would suggest making one list_instances.c which holds all the
INSTANTIATE... definitions of the list types needed in the kernel. This
way we will avoid having two list codes generated for the same type (an
easy accident to make with the macro approach)
*) You would have to somehow separate the "simple" routines which should
be inlined, and the larger ones which should remain function calls. This
would mean that a .c file using the list header would have the inline
functions declared in the list header (using static inline so unused
routines won't bloat the .o), and find it's larger out-of-line routines
in the global list .o.
The reason I'm suggesting doing the above instead of simply
instantiating a list implementation for each type needed, whenever it is
needed, is simply to avoid code bloat.
My only comment for the code would be to require that the link from the
element into the list would always be called "rx_list_backlink" or
whatever (if the list name is "rx_list") - the freedom you have in
specifying what the LINK_NAME is, is useless as I see it, and only adds
to the confusion.
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
next prev parent reply other threads:[~2002-07-24 12:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-23 11:28 PATCH: type safe(r) list_entry repacement: generic_out_cast Neil Brown
2002-07-23 11:47 ` Jakob Oestergaard
2002-07-23 22:07 ` type safe lists (was Re: PATCH: type safe(r) list_entry repacement: generic_out_cast) Joshua MacDonald
2002-07-24 7:39 ` Martin Brulisauer
2002-07-24 8:24 ` Anton Altaparmakov
2002-07-24 9:56 ` Joshua MacDonald
2002-07-24 10:50 ` Martin Brulisauer
2002-07-24 11:58 ` Jakob Oestergaard
2002-07-24 16:49 ` John Alvord
2002-07-25 5:29 ` Greg KH
2002-07-25 6:20 ` Roland Dreier
2002-09-04 13:48 ` Alexander Kellett
2002-09-04 14:27 ` DervishD
2002-07-24 12:22 ` Jakob Oestergaard [this message]
2002-07-24 12:40 ` Joshua MacDonald
2002-07-24 15:15 ` Hans Reiser
2002-07-23 12:42 ` PATCH: type safe(r) list_entry repacement: generic_out_cast Brian Gerst
2002-07-23 16:29 ` Linus Torvalds
2002-07-24 5:25 ` Thunder from the hill
2002-07-23 16:36 ` Christoph Hellwig
2002-07-23 22:58 ` Kevin O'Connor
2002-07-24 12:38 ` PATCH - mark 2: type safe(r) list_entry repacement: container_of Neil Brown
[not found] <20020723114703.GM11081@unthought.net.suse.lists.linux.kernel>
[not found] ` <3D3E75E9.28151.2A7FBB2@localhost.suse.lists.linux.kernel>
2002-07-24 13:23 ` type safe lists (was Re: PATCH: type safe(r) list_entry repacement: generic_out_cast) Andi Kleen
2002-07-24 21:00 ` Linus Torvalds
2002-07-24 23:39 ` Jamie Lokier
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=20020724122232.GT11081@unthought.net \
--to=jakob@unthought.net \
--cc=jmacd@namesys.com \
--cc=linux-kernel@vger.kernel.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