From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11991 Path: news.gmane.org!.POSTED!not-for-mail From: Florian Fainelli Newsgroups: gmane.linux.lib.musl.general,gmane.linux.kernel,gmane.linux.kernel.api Subject: Re: Re: [PATCHv3] uapi libc compat: add fallback for unsupported libcs Date: Mon, 9 Oct 2017 20:30:12 -0700 Message-ID: References: <20170729140259.GA28081@nyan> <6896b985-151e-1dd9-ec91-7ce1300cc45b@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: 8bit X-Trace: blaine.gmane.org 1507606237 542 195.159.176.226 (10 Oct 2017 03:30:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Oct 2017 03:30:37 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 To: musl@lists.openwall.com, Hauke Mehrtens , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, "David S. Miller" , Carlos O'Donell , Felix Janda Original-X-From: musl-return-12004-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 10 05:30:30 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 1e1lFP-00075L-9i for gllmg-musl@m.gmane.org; Tue, 10 Oct 2017 05:30:23 +0200 Original-Received: (qmail 3180 invoked by uid 550); 10 Oct 2017 03:30:27 -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 3159 invoked from network); 10 Oct 2017 03:30:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ahRK2rdsPGOhqivGlUaout0lA9iFhc0srmnYiX4IeQE=; b=M3Pwwi/YeF/cfRUVPB4bJRlD3IkHa367HqB8D8BBi7JjOO7q76yHOQVu48s+UgAGIF In0KiSom9xPOqzf0KXpixfLS5zYYo4arP+XC8X/m+vcgemfa2E8OwxxwExjINSmSy1u5 HmMM7EYl0HxF8orUkKaCRYlxkqPJKyPmEnkhDTIzyrNSHF7TzHxs7K0m4JjqVTl8DE0T xm8nuc9MBJjtH8YIDc+GwciPwglJsAEIuJIZ1t3C/+wnInX0jCW+vSMQ3JlIqQW+995r 1sae5nbC7zGiT+CjCvKjVvCChfvfZEyYhZAT2y5OrO4HOPQUCZh68EUDvR8Sd2pwVxEx uMlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ahRK2rdsPGOhqivGlUaout0lA9iFhc0srmnYiX4IeQE=; b=JAyC05WSb4CyiN4mTpGD9kK9dnPQfEHy0uZbPtzZj3LNgE9dlFclbBm3O9fi0zE/CN nF0LzYg+aQb8HvHxqFev9WSLYjJmD5eOBzVyAIrphpkT/hkgJpwh0u5ifkdN3Rtb/6Gd LLaL9zO3yidFvedBj4tMdUyB1O+o/ws2jLU6htnMAwPVpQAuRU7JVu/+XsYINahNGh+U HdQlH99jABtXMuZPYHgjfR5XO20RkN4aSPCKCFvIMiag2B+SS+TEI+ZaRRLfJSWptw8n hjng7Gdk6BvWw0YeZriIjxdCtCUPfU8/7y89IfyiVybMXe+gVWj2EXsWr1zFVUmhqYje uMzw== X-Gm-Message-State: AMCzsaX2XhbIWMSy9EROKkifnrAUlKc69Xa3TYIvvdjZVGFP4dPpFmuB yhGSkFrq9rhE0ZPcPCYr0+s= X-Google-Smtp-Source: AOwi7QBjwP8PYSz/+CFKTGF8q47jb9SlWbfAfmjJHlwPBftihViheCWWSUA/rwTdoD6qhXKxLtzrfA== X-Received: by 10.157.15.215 with SMTP id m23mr831202otd.260.1507606214855; Mon, 09 Oct 2017 20:30:14 -0700 (PDT) In-Reply-To: <6896b985-151e-1dd9-ec91-7ce1300cc45b@hauke-m.de> Content-Language: en-US Xref: news.gmane.org gmane.linux.lib.musl.general:11991 gmane.linux.kernel:2588197 gmane.linux.kernel.api:24953 Archived-At: Le 10/01/17 à 03:37, Hauke Mehrtens a écrit : > On 07/29/2017 04:02 PM, Felix Janda wrote: >> libc-compat.h aims to prevent symbol collisions between uapi and libc >> headers for each supported libc. This requires continuous coordination >> between them. >> >> The goal of this commit is to improve the situation for libcs (such as >> musl) which are not yet supported and/or do not wish to be explicitly >> supported, while not affecting supported libcs. More precisely, with >> this commit, unsupported libcs can request the suppression of any >> specific uapi definition by defining the correspondings _UAPI_DEF_* >> macro as 0. This can fix symbol collisions for them, as long as the >> libc headers are included before the uapi headers. Inclusion in the >> other order is outside the scope of this commit. >> >> All infrastructure in order to enable this fallback for unsupported >> libcs is already in place, except that libc-compat.h unconditionally >> defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that >> any previous definitions are ignored. In order to fix this, this commit >> merely makes these definitions conditional. >> >> This commit together with the musl libc commit >> >> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258 >> >> fixes for example the following compiler errors when is >> included after musl's : >> >> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr' >> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6' >> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq' >> >> Signed-off-by: Felix Janda >> --- >> v3: Fix typos, add a comment to the file and use #ifndef. >> v2: The only change to the previous version is the commit title and >> message. > > Was this send to the wrong mailing lists? I would like to see this in > the mainline kernel and I am wondering why it neither gets any comments > nor shows up in linux-next. Same here. Without such changes we cannot essentially build upstream kernels in OpenWrt/LEDE using musl-libc without patching kernel headers, which is really not great... -- Florian