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

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

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.

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 support the use of a standard, and working to try and comply with
the standard, and also to work with the standard to fix it as we go.
The mess that was futex return codes before Michael, Torvald and
others started documenting and refining things should show how out
of control some linux syscalls can get.

If we really want better network APIs then we should just be creating
them ourselves, implementing them in Linux, and exporting them via
glibc wrappers/headers. We should make APIs that are *better* than
recvmsg/sendmsg. Once we get a good API we can propose that to POSIX.
Rather than the other way around, which is a half-hearted attempt to
be POSIX compatible, but with enough changes to provided portability
issues and documentation problems.

I will end by giving a counter example...

In POSIX section 2.9.7 it states that 39 filesystem operations need to 
be atomic with respect to eachother given threads in a process. This
is huge performance killer, particularly the write and fstat atomicity.
As of linux 3.14 the two threads calling write at exactly the same time
(on the same fd) will actually get two distinct  offsets, which is good,
you get interleaved writes. The rest of the functions will never, and
should not be, guaranteed atomic (wrt to threads in the same process),
and glibc on linux should never follow POSIX in this case. To support
POSIX we would need userspace IO locks and purposely serialize these
operations.

Each case for conformance should be considered on it's own merit.

Regarding adding all linux syscalls, please see:
https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
and the notes that Adhemerval provided.

-- 
Cheers,
Carlos.