[lkml]   [2008]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/1] x86: Change _node_to_cpumask_ptr to return const ptr
On Tue, Jul 8, 2008 at 8:05 PM, Mike Travis <> wrote:
>>> Note: I did not change node_to_cpumask_ptr() in include/asm-generic/topology.h
>>> as node_to_cpumask_ptr_next() does change the cpumask value.
>> Hmmm. Does it really?
>> #define node_to_cpumask_ptr_next(v, node) \
>> _##v = node_to_cpumask(node)
>> This doesn't seem to modify it?
> Well I thought about it. The pointer (*v) does not change
> but the underlying cpumask variable is updated with the
> cpumask for the (supposedly) new node number. You can see
> that in this code snippet from kernel/sched.c:
> for (i = 1; i < SD_NODES_PER_DOMAIN; i++) {
> int next_node = find_next_best_node(node, &used_nodes);
> node_to_cpumask_ptr_next(nodemask, next_node);
> cpus_or(*span, *span, *nodemask);
> }
> In the optimized (x86_64) case, the pointer is simply modified
> to point to the new node_to_cpumask_map[node] entry. It remains
> a pointer to a const value.
> But the non-optimized version replaces the const cpumask value
> with the new cpumask value. Isn't this breaking the const
> attribute?

No, I think the pointer really should be const. This doesn't guarantee
that the value doesn't change behind our backs, it only prevents us
from modifying it ourselves.


"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036

 \ /
  Last update: 2008-07-08 20:25    [W:0.053 / U:21.496 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site