From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3585 invoked by alias); 9 Jun 2016 14:21:40 -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 3573 invoked by uid 89); 9 Jun 2016 14:21:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Thu, 09 Jun 2016 14:21:00 -0000 From: Joseph Myers To: Carlos O'Donell CC: Adhemerval Zanella , Zack Weinberg , GNU C Library , Florian Weimer Subject: Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919) In-Reply-To: <5758DFF7.5020800@redhat.com> Message-ID: References: <1459175641-12520-1-git-send-email-adhemerval.zanella@linaro.org> <1459175641-12520-3-git-send-email-adhemerval.zanella@linaro.org> <5756D873.1000701@linaro.org> <575886C8.8000401@linaro.org> <5758DFF7.5020800@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-06/txt/msg00309.txt.bz2 On Wed, 8 Jun 2016, Carlos O'Donell wrote: > Regarding adding all linux syscalls, please see: > https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers > and the notes that Adhemerval provided. Note that we have never managed to reach consensus on syscall wrappers. However, I now disagree with the idea of a separate libinux-syscalls.so library, or of only adding to libc.so those syscalls considered appropriate for the OS-independent GNU API. I think that all non-obsolete syscalls that can meaningfully be used outside of glibc in a glibc-using program, even those extremely OS-specific or only likely to be of use to a handful of programs on an OS, should have wrappers added to glibc, and that we should not need to decide when adding them whether they are appropriate for the OS-independent GNU API (although if there is consensus for putting them in the OS-independent GNU API at the time they are added, they should go there at that point - other functions might be added to the OS-independent GNU API later). We *do* still need to decide for such wrappers what the userspace types are to use with them, what the prototype is, what header declares the functions, and how errno and thread cancellation are handled. And we *do* need documentation in the glibc manual for all such wrappers, and testcases in the glibc testsuite (though some such tests may not be able to do more than test that a call to the function compiles and links). -- Joseph S. Myers joseph@codesourcery.com