[PATCH 00/31] cpumask: Provide new cpumask API

From: Mike Travis
Date: Mon Sep 29 2008 - 14:03:09 EST



Ingo Molnar wrote:
>
> could you please send whatever .c changes you have already, so that we
> can have a look at how the end result will look like? Doesnt have to
> build, i'm just curious about how it looks like in practice,
> semantically.
>
> Ingo

Here's one(*) proposal for a new cpumask interface API in a patch
that's compilable. Obviously with a change of this magnitude, a large
number of files are affected. I tried to group them into functional
changes, but there are a lot of "clean up" types of patches, so these
are grouped in the second half by sections. Hopefully this minimizes
the interdependencies between patches.

[* - Rusty has an alternative approach that he'll be submitting shortly.]

The patches in this patchset are:

* Doc files and basic "cleanup" changes.

docs
send_IPI_mask
remove-min

* Base changes to cpumask.h and helper files.

mv-cpumask-alloc
cpumask-base
lib-cpumask

* Minimal changes to let init/main.c compile cleanly.

init_main

* Mechanical changes, mostly automated.

Modify cpu-maps
Get-rid-of-_nr variations
Fix cpumask_of_cpu refs
Remove set_cpus_allowed_ptr
Remove CPU_MASK_ALL_PTR
Modify for_each_cpu_mask
Change first_cpu/next_cpu to cpus_first/cpus_next
Remove node_to_cpumask_ptr

* Sectional changes, to agree with API changes:

acpi
apic
cpu
cpufreq
irq
kernel
misc
mm
pci
rcu
sched
smp
time
tlb
trace
xen

* Allocation of temporary onstack cpumask variables.
(To be supplied. See cpumask_alloc.h for prelim info.)

* Changes to non-x86 architecture files.
(To be supplied.)


These changes should work in the current code. The flag to turn on the
new code is "CONFIG_CPUMASKS_OFFSTACK". This is not yet turned on so
this code should be completely compatible with current code, only laying
down the groundwork for when cpumasks will be "offstack". This should
allow testing to insure that the basic interface is functionally complete.

[Note: testing not yet started.]

--
--
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/