From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11291 Path: news.gmane.org!.POSTED!not-for-mail From: Carlos O'Donell Newsgroups: gmane.linux.lib.musl.general,gmane.linux.kernel,gmane.linux.kernel.api Subject: Re: Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions Date: Tue, 25 Apr 2017 08:29:00 -0400 Organization: Red Hat Message-ID: <9f591383-6e4c-c231-1e5b-68e4b8c16d94@redhat.com> References: <20161111120820.GA435@nyan> <1488977188.4347.134.camel@infradead.org> <459a8faf-4585-5063-3d94-3a1fecfa8289@redhat.com> <21e624b9-7ab1-dcf9-fb1e-c31dd564a283@hauke-m.de> Reply-To: musl@lists.openwall.com 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 1493123361 15142 195.159.176.226 (25 Apr 2017 12:29:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2017 12:29: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@vger.kernel.org To: Hauke Mehrtens , musl@lists.openwall.com, David Woodhouse , Felix Janda , linux-kernel@vger.kernel.org Original-X-From: musl-return-11306-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 25 14:29:13 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1d2zag-0003ko-Ks for gllmg-musl@m.gmane.org; Tue, 25 Apr 2017 14:29:10 +0200 Original-Received: (qmail 17708 invoked by uid 550); 25 Apr 2017 12:29:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17682 invoked from network); 25 Apr 2017 12:29:14 -0000 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=tQ5VjVWSYbPN+DIG0NFvvPGJIrq5ieyE5JQRsnh+X1k=; b=dvg82PIBxVXSf/Xj+Enckb8Fmf78EETjtrQp84SP9V2Ol6Lwf6l75DRfxd8Nki1dRe Ila/Z+6zigZHTq0Y7b1J4BG/9QTV25liFGHAp40ivTOBsqnXBZhRylV1ptgjAsPR8BTA CX3P8rZmhVwLAJzHdYKfzOw5kdo9etqshvbCkcyk9u4v2GlPJS5bpjrv7QnQxMDkq2wj HqAqnmplrJ7z6W1MGn+wwUOQpIzFrla/mna3skCxPqlrxKZixZBvvU4eYsbdo4lE+tBz 4vi7wurbnV8xZe3RtmrKdnrPEO4NpV+cWAlrUCi0jRXp/iw5BVRZ1nGLmquPn2wG017k hASQ== X-Gm-Message-State: AN3rC/59R3tx4CN8DYIisK+xZIyTTHUx2+QysgMpqovhzIcoj45Qjp5d Em8dROLxQm8uV5Od X-Received: by 10.237.35.162 with SMTP id j31mr29952359qtc.117.1493123342554; Tue, 25 Apr 2017 05:29:02 -0700 (PDT) In-Reply-To: <21e624b9-7ab1-dcf9-fb1e-c31dd564a283@hauke-m.de> Content-Language: en-US Xref: news.gmane.org gmane.linux.lib.musl.general:11291 gmane.linux.kernel:2463363 gmane.linux.kernel.api:23091 Archived-At: On 04/25/2017 02:45 AM, Hauke Mehrtens wrote: > On 03/08/2017 05:39 PM, Carlos O'Donell wrote: >> Any header needing compat with a libc includes libc-compat.h (per the >> documented way the model works). With this patch any included linux kernel >> header that also includes libc-compat.h would immediately define all >> the __UAPI_DEF_* constants to 1 as-if it had defined those structures, >> but it has not. >> >> For example, with these two patches applied, the inclusion of linux/if.h >> would define __UAPI_DEF_XATTR to 1, but linux/if.h has not defined >> XATTR_CREATE or other constants, so a subsequent inclusion sys/xattrs.h >> from userspace would _not_ define XATTR_CREATE because __UAPI_DEF_XATTR set >> to 1 indicates the kernel has. >> >> I don't want to read into the model you are proposing and would rather you >> document the semantics clearly so we can all see what you mean. > > What about moving the code from libc-comapt.h into the specific header > files? This way including linux/if.h would not have an impact on > __UAPI_DEF_XATTR, because this is defined in linux/xattr.h. We would > still have a problem when the specific Linux header file gets included > before the libc header file, but at least musl does not support this anyway. The point of libc-compat.h is to contain the libc-related logic to a single header where it can be reviewed easily as a whole for each libc. Headers that include libc-compat.h need not have any libc-related logic, they need only guard their structures with the appropriate __UAPI_DEF* macros per the rules described in libc-compat.h. This way we minimize any changes to the header files and keep the complex logic in one place where the libc authors can discuss it. In glibc right now we support including linux or glibc header files first, and this has always been a requirement from the start. This requirement dictates that the kernel know which libc it's being used with so it can tailor coordination. If musl only needs header coordination in one direction, then support only that direction, but please do not presume to simplify the code by deleting a bunch of things that were worked into the kernel to ensure header inclusion ordering works in both ways. I have lots of customers writing code that includes kernel headers and letting them include headers safely in any order where both headers provide the same define is the simplest thing. If you have a suggestion, please describe your proposed model in detail, and provide a patch that explains and show how it works. -- Cheers, Carlos.