Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?

[KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>]

(7/18/13 5:36 AM), Carlos O'Donell wrote:
> On 07/17/2013 06:56 PM, KOSAKI Motohiro wrote:
> > > Just to clarify:
> > >
> > > kernel/sched/core.c:
> > > ...
> > > 3714 SYSCALL_DEFINE3(sched_getaffinity, pid_t, pid, unsigned int, len,
> > > 3715                 unsigned long __user *, user_mask_ptr)
> > > ...
> > > 3720         if ((len * BITS_PER_BYTE) < nr_cpu_ids)
> > > 3721                 return -EINVAL;
> > >
> > > This code causes EINVAL to be returned when the length of the userspace
> > > buffer is smaller than the size of the mask for ONLINE cpus.
> >
> > No. nr_cpu_ids mean possible cpus. This code mean, if user buffer is less than
> > possible cpus, sched_getaffinity() always return EINVAL.
> > I agree this name is not fully clear. ;-)
>
> This is disappointing because the kernel's sched_getaffinity could work
> with online cpus here and it would save space and map conveniently
> to sysconf(_SC_NPROCESSORS_ONLN).

too bad. I didn't expect such comment because the interface was designed based
on glibc folks request.

> However, glibc would have to handle two distinct behaviours at that point,
> so there is no real benefit.
>
> I think we need _SC_NPROCESSORS_MAX_NP, otherwise users have no useful
> way to determine the maximum number of possible cpus.

Agreed.