Re: [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap basedimplementation

[Paul Jackson]

William wrote:
> Why do I have to put up with this and why do they always come after me?

I do not understand this.  Probably just as well.

> All of their sizes are rounded up to CHAR_BIT*sizeof(cpumask_t)

The number of bits in a mask is CHAR_BIT*sizeof(cpumask_t), yes.
So -- your point being?

> and all of their contents are variable.

No - not unless my commentary describing these maps in the cpumask.h
file in this patch is wrong.  Some of the contents are fixed at boot,
such as cpu_possible_map.  And again, your point being?

> Hmm. /proc/config.gz will do for now.

Only available if IKCONFIG, IKCONFIG_PROC is configured on.

Care to try again ...

Really, if you want to know which CPUs it is possible to have present,
you are describing cpu_possible_map.  While it is an accident of the
current implementation that in the HOTPLUG configuration this is set to
all CPUs from 0 to NR_CPUS-1, i.e. to CPU_MASK_ALL, that fact is not a
design constant, and hence not any basis for designing what information
should be exposed by the kernel to user space.

The user code needs to know the value of these maps, and they need to
know how big (bytes or longs) the maps are, so they can get them across
the kernel/user boundary.

If you claim they need to know whether NR_CPUS is 47 or 48, for hotplug
purposes, then I can only presume that you are assuming that
cpu_possible_map is by design always set to CPU_MASK_ALL. We wouldn't
even have a cpu_possible_map if that were a design constant.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@xxxxxxx> 1.650.933.1373
-
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/