Paul Jackson wrote: > Max K wrote: >>> And for another thing, we already declare externs in cpumask.h for >>> the other, more widely used, cpu_*_map variables cpu_possible_map, >>> cpu_online_map, and cpu_present_map. >> Well, to address #2 and #3 isolated map will need to be exported as well. >> Those other maps do not really have much to do with the scheduler code. >> That's why I think either kernel/cpumask.c or kernel/cpu.c is a better place >> for them. > > Well, if you have need it to be exported for #2 or #3, then that's ok > by me - export it. > > I'm unaware of any kernel/cpumask.c. If you meant lib/cpumask.c, then > I'd prefer you not put it there, as lib/cpumask.c just contains the > implementation details of the abstract data type cpumask_t, not any of > its uses. If you mean kernel/cpuset.c, then that's not a good choice > either, as that just contains the implementation details of the cpuset > subsystem. You should usually define such things in one of the files > using it, and unless there is clearly a -better- place to move the > definition, it's usually better to just leave it where it is.
I was thinking of creating the new file kernel/cpumask.c. But it probably does not make sense just for the masks. I'm now thinking kernel/cpu.c is the best place for it. It contains all the cpu hotplug logic that deals with those maps at the very top it has stuff like /* Serializes the updates to cpu_online_map, cpu_present_map */ static DEFINE_MUTEX(cpu_add_remove_lock); So it seems to make sense to keep the maps in there. Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
