Re: sched_setaffinity usability

[Helge Hafting]

Ingo Molnar wrote:
> * Linus Torvalds <torvalds@xxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/