From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48165 invoked by alias); 21 Apr 2017 18:31:48 -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 46863 invoked by uid 89); 21 Apr 2017 18:31:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=directions, bear, integration, Hx-languages-length:1821 X-HELO: mail-qk0-f172.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:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Uodej7NOIBdpZsS56h0AXo8JWdYbdZ8hzCP0SCVkzBE=; b=RC2Xb4iL4FwuL1sUOd8dBYUToLpgVl7pZhtfTHKYo2IPBr5ouTqVrSbBlLWmN35BhU qqEH9bh/9Z2SRR1v0RjlhpSlzHUxSm5DLL6A0VRXkuX3Xk04FGtS3HORtxbkkpLHKV7Z T3xhm7uphx80XrtZQ67+wL6+R2SdiDT3me1Am3LJ1P1rBBobz/+nveZhhtjJyqx3dTfT 9wXdsFBg0TtFAUKIvlZIgcWR2VJgLyt/qCnranP+kVOZUc8z3hr8N6xkFu2jhVUk8M7p CgHHvWP9k1sakAfxG7fJNJsuPnDd3JXt960ZTEYD9lAKcrmAiCAf59OdeYE7FtKYtrrq kZdQ== X-Gm-Message-State: AN3rC/4UP9aqWQ6Gg/YsqiZzjMI3a0uqI9kfnZXfqUWZMboOl72HRcNv PFeQu72EZWDAMcQXYCOwuw== X-Received: by 10.55.146.135 with SMTP id u129mr12531619qkd.124.1492787794073; Fri, 21 Apr 2017 08:16:34 -0700 (PDT) Subject: Re: [PATCH] : Use an arch-independent system call list on Linux To: Andreas Schwab , Florian Weimer Cc: libc-alpha@sourceware.org, "Dmitry V. Levin" References: <652ab8b9-fbf1-00f3-ff65-faff202cfc07@redhat.com> <0be44a08-16c1-e904-272a-6322f51e7b0c@redhat.com> <086d58f4-f74c-6b8b-52f7-e7b80c51bb40@redhat.com> <20170406143719.GA29170@altlinux.org> <1fd1a90c-1f79-5eef-d9d4-aef7ccc4965c@redhat.com> <87shl2x7xo.fsf@linux-m68k.org> From: Carlos O'Donell Message-ID: Date: Fri, 21 Apr 2017 18:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <87shl2x7xo.fsf@linux-m68k.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-04/txt/msg00471.txt.bz2 On 04/21/2017 08:26 AM, Andreas Schwab wrote: > On Apr 21 2017, Florian Weimer wrote: > >> Do you (and other distributions) build applications against these headers >> as well, or are those only used for building glibc itself? > > These are the kernel UAPI headers, so of course they are used by > everything. TLDR; This introduces changes which can break developer applications, and the only benefit is to glibc. The benefit to rebasing the kernel UAPI headers is that glibc will have an accurate list of SYS_ macros. The disbenefit of the new kernel UAPI headers package is that application developers building applications must bear potentially new integration costs and header conflicts with their own headers (assume glibc does better header inclusion testing, and I have some patches for that). My opinion is that the upstream kernel UAPI headers continue to change without good management of the changes. I have seen at least 3 changes which break header inclusion ordering and that would have caused application build problems. None of the authors of those changes came to talk to us about adding the right guards in glibc to prevent breakage. Worse there have been discussions about deleting existing guards, that change would break header inclusion order in one of the two directions, just to simplify libc-compat.h in the kernel (avoiding needing any libc-specific knowledge). This does not seem conservative enough to me. Are these problems passed on for the users to fix in those distributions that track upstream kernel headers? In the future I will continue to build my own builds with kernel master to try catch all such changes, and add more tests to glibc to catch them too. -- Cheers, Carlos.