From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108488 invoked by alias); 10 May 2017 12:14:27 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 108461 invoked by uid 89); 10 May 2017 12:14:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-qk0-f169.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=i78X6GExwi5Vy3CfuIxHatf36QoCdprDeuAr3RFYWhw=; b=W9f+lqN6o50JQbMqDLCp+SoAs8SklJo4p8ngFRGuBT9H3wH2coP+xpaE07DCB3wZah 2N1454lqXP21mkujmsmuh4x5d/lenaESOoPRA+FoG5PesZlKMf2CF9GAAfITrRvzwosW heafr6289duhPyu6WjJgrt2QpRer0uHc/n2CiQVhKDEXCh6fV+kqBIsxKvmXNK7/t7q/ NE2g7N0XGr3AqUosGKLD8oO+kxN7B/ALYGD9gqVqa7CfuH37qTkQg5YUr8boYnhlKQo4 GFXYpc8OtlXH9k7SzljboL8PsDit3bIZaTEYHYC0TIjMMet1ZBjysNsspjdEftDKFdml bQYg== X-Gm-Message-State: AODbwcDcbzOd7rSJ73QCQGNsJXO/tOwKGWOd72+V1GUPqROm1j+OCV2D AcfpGeHG7XLt+HmT X-Received: by 10.55.104.66 with SMTP id d63mr4742978qkc.260.1494418463566; Wed, 10 May 2017 05:14:23 -0700 (PDT) Subject: Re: Simplify sendmmsg code To: Florian Weimer References: <2c061440-b7c4-985b-c9b9-05d17d952bc1@redhat.com> <4926ca64-c33c-e72e-05fc-29d3f99f1144@linaro.org> Cc: libc-alpha@sourceware.org, "Joseph S. Myers" From: Adhemerval Zanella Message-ID: <5a739df9-0a04-bf4e-323b-699866ef4596@linaro.org> Date: Wed, 10 May 2017 12:14:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-05/txt/msg00236.txt.bz2 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).