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

[Zack Weinberg <zackw at panix dot com>]

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.

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.
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.

(A much more significant issue here is the ridiculous delays in adding
things like gettid() and getrandom().)

> 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.

zw