Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)

[Carlos O'Donell <carlos at redhat dot com>]

On 06/09/2016 09:35 AM, Zack Weinberg wrote:
> On Wed, Jun 8, 2016 at 11:18 PM, Carlos O'Donell <carlos@redhat.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
that easy.

> (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
doesn't work.

-- 
Cheers,
Carlos.