This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc at the Toolchains microconference at LPC 2019
On 6/26/19 12:56 PM, Florian Weimer wrote:
> * Zack Weinberg:
>
>> On Wed, Jun 26, 2019 at 12:39 PM Dmitry V. Levin <ldv@altlinux.org> wrote:
>>> On Wed, Jun 26, 2019 at 06:01:28PM +0200, Florian Weimer wrote:
>>>> glibc system call wrappers are on the agenda:
>>>>
>>>> <https://www.linuxplumbersconf.org/blog/2019/toolchains-microconference-accepted-into-2019-linux-plumbers-conference/>
>>>>
>>>> Will anyone from the glibc community attend and can set the right
>>>> expectations?
>>>
>>> What are the right expectations?
>>
>> Well, _I_ think glibc should provide wrappers for all Linux system
>> calls, except those that cannot be used without stomping on internal
>> glibc data structures (e.g. set_tid_address, set_robust_list, brk) and
>> those that have been completely superseded by newer syscalls. Other
>> people have disagreed with me pretty strenuously, but they haven't
>> done any of the work required to make forward progress on their more
>> conservative policies. I am tempted to post a patch early in the 2.31
>> cycle that adds wrappers for everything, and then threaten to apply it
>> unilaterally unless I hear concrete objections within a week or so.
>
> In my experience, it's been difficult to get reviewers. So what the
> project says it wants and what the project actually makes happen is
> rather different.
It is difficult to get reviewers for *all* patches.
Therefore I don't think this is particular to syscall wrappers.
I've tried hard to review many of your syscall wrappers and make good
on the promise we gave to the kernel community that we would do so.
Lastly, if you do reviews please provide your "Reviewed-by" markers
since it will let me run metrics on how many people we have reviewing
and who they are, and use that information to for a long-term strategy
for getting more reviewers.
> There is currently a requirement that every wrapper needs a manual entry
> (and, presumably, a test case, although I have not tested the waters on
> that). membarrier is not included only because we could not agree on
> the manual text.
And rightly so. I would hope that we all agree that we need documentation
and testing of interfaces in order to provide our users with the information
they need to use these interfaces.
--
Cheers,
Carlos.