Rasmus Villemoes <li...@rasmusvillemoes.dk> writes:
> Maybe third time's the charm...
>
> The four cpumasks cpu_{possible,online,present,active}_bits are
> exposed readonly via the corresponding const variables
> cpu_xyz_mask. But they are also accessible for arbitrary writing via
> the exposed functions set_cpu_xyz. There's quite a bit of code
> throughout the kernel which iterates over or otherwise accesses these
> bitmaps, and having the access go via the cpu_xyz_mask variables is
> simply a useless indirection.Thanks, consider all patches Acked-by: Rusty Russell <ru...@rustcorp.com.au> But to be clear, it has outlived its usefulness, but it was not useless. In particular, there used to be a debug config where 'struct cpumask' wasn't defined, so we could catch people declaring 'struct cpumask' on the stack (or passing by value). There was a plan to remove CONFIG_NR_CPUS (ie. having no compile-time cpu limit), but it seemed overkill and was abandoned. But avoiding 'struct cpumask' (not struct cpumask *) in the core wherever possible was a step towards it. Hope that clarifies, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
