From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11288 Path: news.gmane.org!.POSTED!not-for-mail From: Hauke Mehrtens 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:37:34 +0200 Message-ID: <9373f78c-ff15-fbb5-724a-27152d6f994b@hauke-m.de> References: <20161111120820.GA435@nyan> <1488977188.4347.134.camel@infradead.org> 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 1493102303 28106 195.159.176.226 (25 Apr 2017 06:38:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2017 06:38:23 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Cc: "David S. Miller" , linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Carlos O'Donell To: 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 08:38:18 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 1d2u78-0001p3-Cg for glka-linux-api@m.gmane.org; Tue, 25 Apr 2017 08:38:18 +0200 Original-Received: (majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org) by vger.kernel.org via listexpand id S980847AbdDYGiY (ORCPT ); Tue, 25 Apr 2017 02:38:24 -0400 Original-Received: from hauke-m.de ([5.39.93.123]:35576 "EHLO mail.hauke-m.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S941348AbdDYGiX (ORCPT ); Tue, 25 Apr 2017 02:38:23 -0400 Original-Received: from [192.168.0.100] (ip-109-45-3-139.web.vodafone.de [109.45.3.139]) by mail.hauke-m.de (Postfix) with ESMTPSA id 274CA10016F; Tue, 25 Apr 2017 08:38:16 +0200 (CEST) X-Enigmail-Draft-Status: N1110 In-Reply-To: <1488977188.4347.134.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 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:23079 gmane.linux.lib.musl.general:11288 gmane.linux.kernel:2463110 Archived-At: 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. Hauke