This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>
- Date: Thu, 18 Jul 2013 15:46:52 -0400
- Subject: Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?
- References: <51E42BFE dot 7000301 at redhat dot com> <20130718093506 dot GH5942 at type dot bordeaux dot inria dot fr> <51E7B841 dot 9010805 at redhat dot com> <20130718094411 dot GJ5942 at type dot bordeaux dot inria dot fr>
On 07/18/2013 05:44 AM, Samuel Thibault wrote:
> Carlos O'Donell, le Thu 18 Jul 2013 05:41:21 -0400, a écrit :
>> On 07/18/2013 05:35 AM, Samuel Thibault wrote:
>>> BTW, changing CPU_SETSIZE does not change glibc's ABI: it is only used
>>> in inlines in headers, never in the glibc source code.
>>>
>>> It may however change ABIs of other libraries if they happen to have
>>> put it into their ABI (e.g. expose an explicitly CPU_SETSIZE-lengthed
>>> bitmap)
>>
>> For all intents and purposes it is part of glibc's public ABI,
>
> How so?
I think we are simply talking over eachother and that what
really matters is the ABI guarantees you make as a project,
not specifically what is or is not a strict part of ABI of
the ELF files that constitute the build output.
The community considers CPU_SETSIZE part of the public ABI
and we prevent changes to it as part of the guarantee we offer
the users of our library.
If we change the cpu set size in glibc's headers we would break
interoperability between applications and shared libraries that
expect the type to be of the old size. We try hard to guarantee
to our users that we won't do that.
Does that answer your question?
Cheers,
Carlos.