Messages in this thread | | | Date | Fri, 19 Mar 2004 10:02:35 +0100 | From | Helge Hafting <> | Subject | Re: sched_setaffinity usability |
| |
Ingo Molnar wrote: > * Linus Torvalds <torvalds@osdl.org> wrote: > > >>sysconf() is a user-level implementation issue, and so is something >>like "number of CPU's". Damn, the simplest way to do it is as a >>environment variable, for christ sake! Just make a magic environment >>variable called __SC_ARRAY, and make it be some kind of binary >>encoding if you worry about performance. > > > i am not arguing for any sysconf() support at all - it clearly belongs > into glibc. Just doing 'man sysconf' shows that it should be in > user-space. No argument about that. > > But how about the original issue Ulrich raised: how does user-space > figure out the NR_CPUS value supported by the kernel? (not the current # > of CPUs, that can be figured out using /proc/cpuinfo) > > one solution would be what you suggest: to build some sort of /etc/info > file that glibc can access, which file is build during the kernel build > and contains the necessary constants. One problem with this approach is > that a user could boot via any arbitrary kernel, how does glibc (or even > a supposed early-init info-setup mechanism) know what info belongs to > which kernel? Kernel version numbers are not required to be unique. A > single non-modular bzImage can be used to have a fully working > userspace. Right now the kernel and glibc is isolated pretty much and > this gives us flexibility.
Let the compile create that info file. Then handle it much like a module, except that it is a "module" without any code. I.e. copy it to /lib/modules/<kernelversion> if installing modules, or stuff the file into the initrd if making an initrd.
Now it is in a place specific to the kernel, where a library can find it.
Helge Hafting
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |