This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Simplify sendmmsg code
On 10/05/2017 04:41, Florian Weimer wrote:
> On 05/09/2017 10:58 PM, Adhemerval Zanella wrote:
>
>> So if I understood correctly, the idea is to *remove* sendmmsg on resolv code then?
>> Because now with __ASSUME_SENDMMSG being used as default for Linux this code will
>> be used on all architectures.
>
> Yes, once we have two sockets, we need to call sendmsg for each one separately. But that's an *algorithmic* change, it's not simply about replacing one call to sendmmsg with two to sendmsg. But that would be fine as an intermediate step as well if you want to simplify things in this way.
>
Right, so I think we an proceed with the removal of sendmmsg and later change the
two socket utilization.
>> In any case, my understanding for sendmmsg is it is a GNU extension (similar to
>> pwritev), so the idea is to have a fallback usable code on sysdeps/{posix,unix}
>> to we do not need to actually tests its usability in the rest of glibc code.
>
> As far as I understand things, both sendmmsg and pwritev cannot be emulated in userspace because the fallback implementation would not have the atomicity guarantees provided by the kernel implementation. IMHO, the generic versions should just return ENOSYS (or not linked in at all, so that configure scripts can note their absence).
Indeed the emulation brings a lot of issue, but it allows us to use the system
specific syscalls on generic code without relying on additional checks for
functionality existence. However I think we can to Linux optimizations in
generic code less intrusive way if necessary with a different approach, maybe
by implementing the functionally in a more constrained way and reimplement
in the target system.
What I would like to avoid is multiple build option for the same implementation
which are not actually tested and makes us with non exercised code paths
(in a lot of time dead code).