This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for API sources
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Tue, 17 Nov 2015 22:40:51 +0000
- Subject: Re: Principles for API sources
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511061326480 dot 10753 at digraph dot polyomino dot org dot uk>
To summarize discussion so far:
I think we have general support for the given principles (including
selectively accepting modern BSD APIs on the basis of widespread use, even
where there are deficiencies in those APIs), though with disagreement on
the quality of API review that takes place in the BSD and Linux kernel
contexts.
There seems to be support for the binary floating-point APIs from TS 18661
parts 1, 3 and 4, but only one person replied to
<https://sourceware.org/ml/libc-alpha/2015-11/msg00162.html> (and it was
suggested that there might be, hypothetically, concerns that no-one has
actually said they have). This is assuming any substantial implementation
piece starts with a coherent design based on a good global understanding
of glibc libm issues and of TS 18661, and that such a design then gets
community consensus, rather than starting by hacking up whatever first
comes to mind. Views from more people on these APIs would be desirable.
There's support for TR 24731-2 (Dynamic Allocation Functions) APIs
<https://sourceware.org/ml/libc-alpha/2015-11/msg00230.html>.
Thread-safe timezone interfaces were mentioned in passing
<https://sourceware.org/ml/libc-alpha/2015-11/msg00238.html>, but there
hasn't been a separate proposal for them.
Following <https://sourceware.org/ml/libc-alpha/2015-11/msg00233.html>,
the current consensus seems to be against C11 Annex K functions unless
they become widely used. C11 threads have support as an API set; the
other ISO C TR / TS / standard optional APIs I mentioned didn't receive
discussion, but I wasn't making any explicit proposals regarding them
anyway.
There is no consensus so far on what to do with Linux kernel syscalls that
are *not* appropriate for the OS-independent GNU API. Previously there
were objections to putting them in libc.so.N; now there are objections to
putting them in a separate libinux-syscalls.so.1. So this still needs to
be discussed further.
The more specific proposals I made regarding appropriateness of particular
syscalls for the OS-independent GNU API in
<https://sourceware.org/ml/libc-alpha/2015-11/msg00373.html> still need to
be discussed.
--
Joseph S. Myers
joseph@codesourcery.com