public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nathan Lynch <ntl@pobox.com>
To: lkml <linux-kernel@vger.kernel.org>
Cc: colpatch@us.ibm.com, Anton Blanchard <anton@samba.org>
Subject: topology api confusion
Date: Fri, 22 Jul 2005 16:33:16 -0500	[thread overview]
Message-ID: <20050722213316.GE17865@otto> (raw)

We need some clarity on how asm-generic/topology.h is intended to be
used.  I suspect that it's supposed to be unconditionally included at
the end of the architecture's topology.h so that any elements which
are undefined by the arch have sensible default definitions.  Looking
at 2.6.13-rc3, this is what ppc64, ia64, and x86_64 currently do,
however i386 does not (i386 pulls in the generic version only when
!CONFIG_NUMA).

The #ifndef guards around each element of the topology api
cannot serve their apparent intended purpose when the architecture
implements a given bit as a function instead of a macro
(e.g. cpu_to_node in ppc64):

----

asm-generic/topology.h:

#ifndef cpu_to_node
#define cpu_to_node(cpu)        (0)
#endif

----

asm-ppc64/topology.h:

static inline int cpu_to_node(int cpu)
{
        int node;

        node = numa_cpu_lookup_table[cpu];
	....

----

Since ppc64 unconditionally includes asm-generic/topology.h, all uses
of cpu_to_node are preprocessed to (0).  Similar damage occurs with
every other topology function which happens to be a real function
instead of a macro.  I'm surprised my ppc64 numa systems even boot ;)

If the intent is that the architecture is free to define only a subset
of the api and include the generic header for fallback definitions,
then we need to do the #ifndef __HAVE_ARCH_FOO thing, no?  That is,
the code above would look like:

----

asm-generic/topology.h:

#ifndef __HAVE_ARCH_CPU_TO_NODE
#define cpu_to_node(cpu)        (0)
#endif

----

asm-ppc64/topology.h:

#define __HAVE_ARCH_CPU_TO_NODE
static inline int cpu_to_node(int cpu)
{
        int node;

        node = numa_cpu_lookup_table[cpu];
	....

----

Thought I'd ask for input first since this would involve a sweep of
include/asm-*.


Nathan

             reply	other threads:[~2005-07-23  6:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-22 21:33 Nathan Lynch [this message]
2005-07-25 21:41 ` topology api confusion Matthew Dobson
2005-07-25 23:25   ` Nathan Lynch
2005-07-26 15:16   ` Bill Davidsen
2005-08-01  5:07 ` Anton Blanchard
2005-08-01  5:22   ` Nathan Lynch
2005-08-01  8:10   ` Paul Mackerras

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=20050722213316.GE17865@otto \
    --to=ntl@pobox.com \
    --cc=anton@samba.org \
    --cc=colpatch@us.ibm.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