From mboxrd@z Thu Jan 1 00:00:00 1970 From: Loic Domaigne Subject: Re: For review: pthread_setaffinity_np.3 Date: Sat, 15 Nov 2008 20:41:05 +0100 Message-ID: <491F25D1.8020007@domaigne.com> References: <4916133A.8060209@domaigne.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, josv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, "brian m. carlson" , Bert Wesarg , Stefan Puiu , Karsten Weiss List-Id: linux-man@vger.kernel.org Hi Michael! Looks good to me. I have only one minor comment left, regarding EINVAL=20 for pthread_setaffinity_np(): > .TP > .BR EINVAL > .RB ( pthread_setaffinity_np ()) > .I cpuset > specified a CPU that was outside the set supported by the kernel. > (The kernel configuration option > .BR CONFIG_NR_CPUS > defines the range of the set supported by the kernel data type > .\" cpumask_t > used to represent CPU sets.) > .\" The raw sched_getaffinity() system call returns the size (in byte= s) > .\" of the cpumask_t type. In the light of Bert's comment, it seems that the Linux kernel folks=20 wants to make the cpumask_t dynamic. So CONFIG_NR_CPUS might become=20 obsolete in the future... But for now, your explanation is fine. Cheers, Lo=EFc. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html