Re: [PATCH] cputopology: Always define CPU topology information[4th try]

From: Andrew Morton
Date: Thu Jun 05 2008 - 00:47:47 EST


On Wed, 4 Jun 2008 16:44:56 +0100 Ben Hutchings <bhutchings@xxxxxxxxxxxxxx> wrote:

> Not all architectures and configurations define CPU topology information.
> This can result in an empty topology directory in sysfs, and requires
> in-kernel users to protect all uses with #ifdef - see
> <http://marc.info/?l=linux-netdev&m=120639033904472&w=2>.
>
> The documentation of CPU topology specifies what the defaults should be
> if only partial information is available from the hardware. So we can
> provide these defaults as a fallback.
>
> This patch:
>
> - Adds default definitions of the 4 topology macros to <linux/topology.h>
> - Changes drivers/base/topology.c to use the topology macros unconditionally
> and to cope with definitions that aren't lvalues
> - Updates documentation accordingly

See, this is what I meant. After your patch we have:

#ifdef arch_provides_topology_pointers
#define define_siblings_show_map(name) \
static ssize_t show_##name(struct sys_device *dev, char *buf) \
{ \
unsigned int cpu = dev->id; \
cpumask_t siblings = topology_##name(cpu); \
return show_cpumap(0, &siblings, buf); \
}

#define define_siblings_show_list(name) \
static ssize_t show_##name##_list(struct sys_device *dev, char *buf) \
{ \
unsigned int cpu = dev->id; \
cpumask_t siblings = topology_##name(cpu); \
return show_cpumap(1, &siblings, buf); \
}

#else
#define define_siblings_show_map(name) \
static ssize_t show_##name(struct sys_device *dev, char *buf) \
{ \
unsigned int cpu = dev->id; \
cpumask_t mask = topology_##name(cpu); \
return show_cpumap(0, &mask, buf); \
}

#define define_siblings_show_list(name) \
static ssize_t show_##name##_list(struct sys_device *dev, char *buf) \
{ \
unsigned int cpu = dev->id; \
cpumask_t mask = topology_##name(cpu); \
return show_cpumap(1, &mask, buf); \
}
#endif

they're the same!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/