From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 726B22ECAB for ; Fri, 6 Sep 2024 18:43:02 +0200 (CEST) Received: (qmail 23724 invoked by uid 550); 6 Sep 2024 16:42:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23680 invoked from network); 6 Sep 2024 16:42:58 -0000 Date: Fri, 6 Sep 2024 12:42:49 -0400 From: Rich Felker To: jane400 Cc: musl@lists.openwall.com Message-ID: <20240906164249.GO32249@brightrain.aerifal.cx> References: <20240906114930.17884-1-jane400@postmarketos.org> <20240906124533.GU10433@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Subject: Re: [musl] [PATCH] sys/prctl.h: use linux uapi header On Fri, Sep 06, 2024 at 04:12:23PM +0200, jane400 wrote: > On 06.09.24 14:45, Rich Felker wrote: > > On Fri, Sep 06, 2024 at 01:49:30PM +0200, jane400 wrote: > > > The file also includes backports until 2023 for older kernels. > > > > > > There are no exisiting UAPI guards in the kernel for this header > > > and as complex projects like systemd sometimes use both, it was > > > easiest to just use the defintions from the kernel directly instead > > > of copying in them. This way we're never redefining stuff in end-user > > > applications and get the benefit of using the latest API that is > > > available on this system. > > Using both is not a supported usage. This comes up in multiple places > > other than sys/prctl.h, like lots of network stuff, and the > > applications doing it just need to be fixed. Generally we do not use > > uapi headers at all from musl, and offer a working compilation > > environment without uapi headers installed. This would also be a > > breaking change if we ever needed to call prctls internally from libc, > > as then building musl itself would depend on kernel headers. > > Another solution of course is expanding the linux/libc-compat.h a lot and > use the `#if !__UAPI_DEF_FOO` in musl, as intended by the kernel. I can poke > at bit at the kernel and bring that forward if you want? We intentionally don't support having types defined from the kernel headers because of ways they could potentially disagree. The other direction, musl defining the __UAPI_* macros to suppress kernel header definitions, is supported, and should be acceptable to add here if the kernel honored it. This requires including the libc headers first, which is already the policy for network headers. Rich