From: Chris Metcalf <cmetcalf@tilera.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH] arch/tile: Add driver to enable access to the user dynamic network.
Date: Fri, 2 Jul 2010 08:19:36 -0400 [thread overview]
Message-ID: <4C2DD958.7030005@tilera.com> (raw)
In-Reply-To: <201006282134.55166.arnd@arndb.de>
[The question is how to use <linux/list.h> from within <asm/processor.h>.]
On 6/28/2010 3:34 PM, Arnd Bergmann wrote:
>> I think the only "true" fix would be to have a new <linux/list_types.h>
>> > header that provides list_head (and presumably hlist_head and
>> > hlist_node), which <linux/list.h> would include, as would our
>> > <asm/processor.h>. This is certainly in line with recent
>> > header-separation changes (e.g. mm_types.h). Would there be interest in
>> > a change like this? I implemented it in my tree, and if it sounds
>> > plausible to you, I'll send out a git diff, but it looks pretty much
>> > exactly like this description :-)
>>
> Yes, I think that would be a reasonable change.
>
> Another alternative might be to move the prefetch stuff from asm/processor.h
> to asm/prefetch.h on all architectures, which also breaks the dependency loop,
> unless I'm mistaken again
In principle I like the <asm/prefetch.h> idea, but I'm concerned that
the #include of <asm/system.h> from <linux/list.h> will recursively
include <asm/processor.h> on some platforms; for example, s390 and
xtensa include it directly. We (tile) were including it indirectly via
<asm/irqflags.h>, though this seems to be a spurious include on our
part, but other platforms may also include it indirectly. To be fair,
I'm not sure why <asm/system.h> is included from <linux/list.h>. It
doesn't seem required for a tile build, at least, but no doubt it was
put there for some reason.
So, if there's a good reason for it to be there, I'd say that pushes us
back toward a separate <linux/list_types.h>. Otherwise we can
investigate splitting out the prefetch content on every platform to
<asm/prefetch.h> (presumably creating some empty <asm/prefetch.h>
headers on architectures that just use the gcc builtin) and adding new
#includes of <asm/prefetch.h> to files that reference the prefetch
functionality. Arnd and other list folks, what's your instinct?
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
WARNING: multiple messages have this Message-ID (diff)
From: Chris Metcalf <cmetcalf@tilera.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: <linux-kernel@vger.kernel.org>, <linux-arch@vger.kernel.org>
Subject: Re: [PATCH] arch/tile: Add driver to enable access to the user dynamic network.
Date: Fri, 2 Jul 2010 08:19:36 -0400 [thread overview]
Message-ID: <4C2DD958.7030005@tilera.com> (raw)
In-Reply-To: <201006282134.55166.arnd@arndb.de>
[The question is how to use <linux/list.h> from within <asm/processor.h>.]
On 6/28/2010 3:34 PM, Arnd Bergmann wrote:
>> I think the only "true" fix would be to have a new <linux/list_types.h>
>> > header that provides list_head (and presumably hlist_head and
>> > hlist_node), which <linux/list.h> would include, as would our
>> > <asm/processor.h>. This is certainly in line with recent
>> > header-separation changes (e.g. mm_types.h). Would there be interest in
>> > a change like this? I implemented it in my tree, and if it sounds
>> > plausible to you, I'll send out a git diff, but it looks pretty much
>> > exactly like this description :-)
>>
> Yes, I think that would be a reasonable change.
>
> Another alternative might be to move the prefetch stuff from asm/processor.h
> to asm/prefetch.h on all architectures, which also breaks the dependency loop,
> unless I'm mistaken again
In principle I like the <asm/prefetch.h> idea, but I'm concerned that
the #include of <asm/system.h> from <linux/list.h> will recursively
include <asm/processor.h> on some platforms; for example, s390 and
xtensa include it directly. We (tile) were including it indirectly via
<asm/irqflags.h>, though this seems to be a spurious include on our
part, but other platforms may also include it indirectly. To be fair,
I'm not sure why <asm/system.h> is included from <linux/list.h>. It
doesn't seem required for a tile build, at least, but no doubt it was
put there for some reason.
So, if there's a good reason for it to be there, I'd say that pushes us
back toward a separate <linux/list_types.h>. Otherwise we can
investigate splitting out the prefetch content on every platform to
<asm/prefetch.h> (presumably creating some empty <asm/prefetch.h>
headers on architectures that just use the gcc builtin) and adding new
#includes of <asm/prefetch.h> to files that reference the prefetch
functionality. Arnd and other list folks, what's your instinct?
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
next prev parent reply other threads:[~2010-07-02 12:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-25 21:00 [PATCH] arch/tile: Add driver to enable access to the user dynamic network Chris Metcalf
2010-06-26 11:16 ` Arnd Bergmann
2010-06-27 17:00 ` Chris Metcalf
2010-06-28 11:12 ` Arnd Bergmann
2010-06-28 15:23 ` Chris Metcalf
2010-06-28 19:34 ` Arnd Bergmann
2010-07-02 12:19 ` Chris Metcalf [this message]
2010-07-02 12:19 ` Chris Metcalf
2010-07-02 16:11 ` Arnd Bergmann
2010-07-02 17:41 ` [PATCH] Break out types from <linux/list.h> to <linux/list_types.h> Chris Metcalf
2010-07-02 17:41 ` Chris Metcalf
2010-07-02 19:19 ` Matthew Wilcox
2010-07-02 19:33 ` Chris Metcalf
2010-07-02 19:33 ` Chris Metcalf
2010-07-02 20:48 ` Matthew Wilcox
2010-07-02 21:09 ` Chris Metcalf
2010-07-02 21:09 ` Chris Metcalf
2010-07-03 8:44 ` Alexey Dobriyan
2010-07-03 9:00 ` Arnd Bergmann
2010-07-04 1:47 ` Chris Metcalf
2010-07-04 1:47 ` Chris Metcalf
2010-07-04 3:22 ` Matthew Wilcox
2010-07-02 20:43 ` Arnd Bergmann
2010-07-02 21:10 ` Christoph Hellwig
2010-07-02 17:52 ` [PATCH] arch/tile: Add driver to enable access to the user dynamic network Chris Metcalf
2010-07-02 17:52 ` Chris Metcalf
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=4C2DD958.7030005@tilera.com \
--to=cmetcalf@tilera.com \
--cc=arnd@arndb.de \
--cc=linux-arch@vger.kernel.org \
--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 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.