On Fri, Mar 03, 2006 at 09:01:57AM -0800, Luck, Tony wrote:
> - for_each_node(cnode) {
> + for (cnode = 0; cnode < num_cnodes; cnode++) {
>
> Do we really need to fix "for_each_node()" ... having a macro
> named this way that doesn't actually loop over all nodes looks
> like an invitation to get things wrong in the future.
I don't think that will work in the short term. Once we
get to ACPI3.0, yes.
The problem is that SN & the generic kernel are not in agreement
on the definition of a "node". There are several problems.
ACPI2.0 limits the total number of nodes to 256 (PXM), SN needs
more.
In addition, it is difficult to describe IO-only nodes to the
generic kernel. We would need SRAT entries for IO-only nodes
but those tables don't currently exist. Even if they did, we still
have the 256 node limit.
As an interim & admittedly "hackey" solution, we have introduced the
notion of "cnodes". For cpu & memory nodes, the cnode number is
the same as the nid (generic kernel node number). IO nodes are
guaranteed to have numbers assigned after the last nid. IO nodes
may have number >= 256.
Only SN code is aware of cnodes. For example, IO cnodes are not in any
of the node maps: node_online_map, node_possible_map, etc.
IO cnodes don't have many (any?) of the usual per-node tables.
Perhaps for consistency, we should add an SN macro:
for_each_cnode(cnode)
or
for_each_sn_cnode(cnode) # to indicate this is SN only
All of these ugly hacks will go away when we get to ACPI3.0.
-
: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|