lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 04 Feb 2008 20:08:29 -0800 From: Max Krasnyansky <maxk@...lcomm.com> To: Paul Jackson <pj@....com> CC: a.p.zijlstra@...llo.nl, linux-kernel@...r.kernel.org, mingo@...e.hu, srostedt@...hat.com, ghaskins@...ell.com Subject: Re: Integrating cpusets and cpu isolation [was Re: [CPUISOL] CPU isolation extensions] 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists