Re: sched_setaffinity usability

[Helge Hafting <helgehaf@aitel.hist.no>]

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