From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11290 Path: news.gmane.org!.POSTED!not-for-mail From: Carlos O'Donell Newsgroups: gmane.linux.kernel.api,gmane.linux.lib.musl.general,gmane.linux.kernel Subject: Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions Date: Tue, 25 Apr 2017 08:13:15 -0400 Organization: Red Hat Message-ID: References: <20161111120820.GA435@nyan> <1488977188.4347.134.camel@infradead.org> <9373f78c-ff15-fbb5-724a-27152d6f994b@hauke-m.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1493122401 29744 195.159.176.226 (25 Apr 2017 12:13:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2017 12:13:21 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 Cc: "David S. Miller" , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Hauke Mehrtens , musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org, Felix Janda , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Original-X-From: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Tue Apr 25 14:13:17 2017 Return-path: Envelope-to: glka-linux-api@m.gmane.org Original-Received: from vger.kernel.org ([209.132.180.67]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d2zLI-0001jp-RK for glka-linux-api@m.gmane.org; Tue, 25 Apr 2017 14:13:17 +0200 Original-Received: (majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org) by vger.kernel.org via listexpand id S1947297AbdDYMNU (ORCPT ); Tue, 25 Apr 2017 08:13:20 -0400 Original-Received: from mail-qt0-f169.google.com ([209.85.216.169]:35080 "EHLO mail-qt0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1947294AbdDYMNT (ORCPT ); Tue, 25 Apr 2017 08:13:19 -0400 Original-Received: by mail-qt0-f169.google.com with SMTP id y33so137532205qta.2 for ; Tue, 25 Apr 2017 05:13:19 -0700 (PDT) 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=WkaCcB/IQvIU0DF3Zf1XtFYRTNzJEbJSF/EcCvVbiLQ=; b=H37YzVU8dIFiy2uEcLqtkhO5xJ4PRDhzerVq4fFdaSjjKJBm1SKq/44Ep9nvLhnTs9 WA7xTvCIBsiO+92dvpEpLqWcGAqUiEgQDLxjhYDHMKNeDutMlICHby61zeWkc+iIRK5h vpCeumEpIDEx2Gy+O/rdhsagviRQ63PT63WH5jDeC8kgw6zy8AjeDoDx/ap5/ZaGv3Eg 5Ju7BFKJpYY8nSqArWZouOLyPNuH+tKD+yDO5v9UqAQQXgJqY0sLHUTMhmZH1ezTrYRA +22gX5SwFljFQSUTHo8BJoEtYtWzr9vBLbSV/+FvVpSZFfBZpvoPgXGLzZ7vkExzhYa9 fZmA== X-Gm-Message-State: AN3rC/575VGlAR/K/yuwO1V/MV28yv/KtcQdUeiLnBxgSES/nm/BoHRy vqJ7MmsCp/PxVD2x X-Received: by 10.237.58.103 with SMTP id n94mr32793321qte.42.1493122398485; Tue, 25 Apr 2017 05:13:18 -0700 (PDT) Original-Received: from [192.168.1.200] (otwaon234vw-lp130-01-184-145-137-27.dsl.bell.ca. [184.145.137.27]) by smtp.gmail.com with ESMTPSA id q45sm14965132qtb.56.2017.04.25.05.13.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 05:13:17 -0700 (PDT) In-Reply-To: <9373f78c-ff15-fbb5-724a-27152d6f994b-5/S+JYg5SzeELgA04lAiVw@public.gmane.org> Content-Language: en-US Original-Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Precedence: bulk List-ID: X-Mailing-List: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Xref: news.gmane.org gmane.linux.kernel.api:23083 gmane.linux.lib.musl.general:11290 gmane.linux.kernel:2463339 Archived-At: On 04/25/2017 02:37 AM, Hauke Mehrtens wrote: > > > On 03/08/2017 01:46 PM, David Woodhouse wrote: >> On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote: >>> Currently, libc-compat.h detects inclusion of specific glibc headers, >>> and defines corresponding _UAPI_DEF_* macros, which in turn are used in >>> uapi headers to prevent definition of conflicting structures/constants. >>> There is no such detection for other c libraries, for them the >>> _UAPI_DEF_* macros are always defined as 1, and so none of the possibly >>> conflicting definitions are suppressed. >>> >>> This patch enables non-glibc c libraries to request the suppression of >>> any specific interface by defining the corresponding _UAPI_DEF_* macro >>> as 0. >> >> Ick. It's fairly horrid for kernel headers to be reacting to __GLIBC__ >> in any way. That's just wrong. >> >> It makes more sense for C libraries to define the __UAPI_DEF_xxx for >> themselves as and when they add their own support for certain things, >> and for the kernel not to have incestuous knowledge of them. >> >> The part you add here in the #else /* !__GLIBC__ */ part is what we >> should do at *all* times. >> >> I understand that we'll want to grandfather in the glibc horridness, >> but let's make it clear that that's what it is, by letting it set the >> appropriate __UAPI_DEF_xxx macros to zero, and then continue through to >> your new part. Something like this (incremental to yours): > > Felix's and this change and are looking better than my patches here: > https://lkml.org/lkml/2017/3/12/235 > > Is someone working on brining this into the mainline kernel? > > Is it correct that only the comments should be improved? > musl only supports including the musl header files before the kernel > anyway, I assume that it is not needed to make the kernel uapi code > support also the other order. Please repost to linux-api so other relevant C library authors can review the changes and comment on how they might be harmonized. Whether or not you support both inclusion orders, kernel first, or libc first, is a property of your libc implementation. Today glibc aims to support both inclusion orders since we see applications with either order, and the ordering should not matter in this case. You either get one or the other without needing to know any special rules about header ordering. -- Cheers, Carlos.