public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  reply	other threads:[~2010-07-02 12:19 UTC|newest]

Thread overview: 20+ 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 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 19:19                 ` Matthew Wilcox
2010-07-02 19:33                   ` Chris Metcalf
2010-07-02 20:48                     ` Matthew Wilcox
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  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

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox