This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
If one looks though enough kernel versions, one finds that some of them
differ in what they will accept for the len. Some produce EINVAL if
len!=sizeof(long), others (especially Altix) produce EINVAL if len is
too short to cover all the machine's CPUs. I think I recall finding one
that was even happy w/ len==0. So, even if one ignores the 2-argument
version in some 2.5.x kernels, the caller needs to know if the len to
pass should always be sizeof(long), or if it should reflect the true
number of CPUs present (as one must on an Altix).
Bogdan Costescu wrote:
> On Thu, 8 Dec 2005, Jeff Squyres wrote:
>> Check out http://svn.open-mpi.org/svn/ompi/trunk/opal/mca/paffinity/
>> linux/paffinity_linux.h -- there's a big comment in that file about
>> the problem, to include descriptions of the 3 APIs.
> I'm sorry, but that is not quite what I wrote about in my message. The
> comments refer to the _glibc_ view of the functions, at least I
> couldn't see how they map to my reading of the _kernel_ source code.
> Let's take one that is specifically mentioned there: Mandrake 10.0,
> kernel based on 2.6.3, in file kernel/sched.c there is the function:
> * sys_sched_setaffinity - set the cpu affinity of a process
> * @pid: pid of the process
> * @len: length in bytes of the bitmask pointed to by user_mask_ptr
> * @user_mask_ptr: user-space pointer to the new cpu mask
> asmlinkage long sys_sched_setaffinity(pid_t pid, unsigned int len,
> unsigned long __user *user_mask_ptr)
> which again has 3 arguments that look exactly like the ones that I
> mentioned previously. I don't have access to the source code of
> the SGI Altix kernel, so I can't check the other one mentioned there
> as a 2-args function. But so far all _kernel_ prototypes of the
> function that I have looked at are exactly the same with 3 arguments.
> The solution that I proposed works much like a statically linked
> binary - it calls via a syscall the _kernel_ function that has a
> constant (so far) prototype. It doesn't call the _glibc_ function that
> changes prototype.
Paul H. Hargrove PHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900