This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>
- Date: Fri, 10 Jun 2016 14:01:23 -0400
- Subject: Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)
- Authentication-results: sourceware.org; auth=none
- References: <1459175641-12520-1-git-send-email-adhemerval dot zanella at linaro dot org> <1459175641-12520-3-git-send-email-adhemerval dot zanella at linaro dot org> <a963950f-bb21-be79-bddd-8379b588378a at panix dot com> <5756D873 dot 1000701 at linaro dot org> <CAKCAbMgk7vtMFoXKJ45TwnFv7gqNesNk0AuSRHvg58XMSMaQTg at mail dot gmail dot com> <575886C8 dot 8000401 at linaro dot org> <5758DFF7 dot 5020800 at redhat dot com> <CAKCAbMj_UP4Dpidn5nJ1xnZY0KK3KYkHiWgmTXrcQT+bNKjJBQ at mail dot gmail dot com>
On 06/09/2016 09:35 AM, Zack Weinberg wrote:
> On Wed, Jun 8, 2016 at 11:18 PM, Carlos O'Donell <email@example.com> wrote:
>> On 06/08/2016 04:57 PM, Adhemerval Zanella wrote:
>>> On 08/06/2016 17:15, Zack Weinberg wrote:
>>>> What would persuade you to accept *my* position on this issue?
>>> I am stating we follow POSIX to very reason we follow other technical
>>> standard: to provide libc compatibility.
>> There are some places where POSIX and Linux disagree.
>> In as much as we possibly can we should try to standardize on POSIX.
> Right, so as I have been saying all along, I don't agree with this; I
> think it is *more important* to faithfully reflect the semantics of
> each supported kernel. If that means that glibc-on-Linux has
> different semantics than glibc-on-FreeBSD (for instance), well, that
> was probably unavoidable anyway.
That's fine so long as you don't pretend to be POSIX-compatible.
> The reason for this is that POSIX is very slow, and the C library
> should not stand in the way of *improvements* to the kernel interface.
It doesn't stand in the way. We have lots of interfaces that are
non-POSIX and we aren't touching them.
> The case we're arguing about is relatively minor, but maybe someone
> has an actual need for size_t-sized ancillary data buffers - I don't
> think we should be judging whether that is a valid use case.
The problem I have with this line of argument is that a standards-conforming
interface name was taken and changed.
If you really wanted size_t sized ancillary data buffers we should have
just declared a different type and new functions to handle that. It's
> (A much more significant issue here is the ridiculous delays in adding
> things like gettid() and getrandom().)
There are no delays in adding gettid or getrandom, there are only the
lack of skilled people willing to do the work at level of quality required
of a core library implementation.
>> Each decision should be done on a case-by-base basis, and I think in
>> this case of recvmsg/sendmsg it is possible to comply with POSIX without
>> serious problems. I've only seen rare examples of theoretical breakage,
>> and the reported dlsym issue simply needs fixing in the dynamic loader.
> I do not think the reported dlsym issue is a simple matter to fix. I
> haven't sat down and worked it out, but I am fairly sure it is
> possible, for most symbols that glibc exposes multiple versions of, to
> construct a pair of interposition modules which are black-box
> indistinguishable except that one of them needs version A and the
> other needs version B -- which is to say, whatever dlsym("name",
> RTLD_NEXT) does, it's going to be wrong for one of them. Which is why
> there is dlvsym()... but changing the semantics of dlsym() strikes me
> as asking for much greater breakage.
The entire dlsym/dlvsym discussion is a red-herring. At some point you'll
need to interpose yourself in front of a versioned interface and you'll
need two things to do it properly:
* A versioned symbol of your own.
* Use of dlvsym().
Anything that doesn't work with this setup is a bug we need to fix.
Fixing dlsym() is a required fix because the semantics are just plain
wrong, and it happened to fix the present use case, but eventually it