From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carlos O'Donell Subject: Re: Continuing the UAPI split Date: Thu, 7 Nov 2019 17:32:01 -0500 Message-ID: <70a264b5-427f-fa6e-7f70-768724202d14@redhat.com> References: <0B17C6F2-DC2B-4192-B4AD-BD11D6B9F2B6@ubuntu.com> <87zhh7j38y.fsf@oldenburg2.str.redhat.com> <086ffddf-553f-453d-a046-4d5e6abead21@redhat.com> <875zjvo2be.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org In-Reply-To: <875zjvo2be.fsf@mid.deneb.enyo.de> To: Florian Weimer Cc: Szabolcs Nagy , Elichai Turkel , nd , Christian Brauner , "linux-api@vger.kernel.org" , libc-alpha List-Id: linux-api@vger.kernel.org On 11/7/19 3:32 PM, Florian Weimer wrote: > * Carlos O'Donell: >=20 >> On 11/7/19 11:21 AM, Szabolcs Nagy wrote: >>>> Or just giving up and telling users they can't just directly include >>>> both libc headers and kernel headers? >>> >>> including both libc and linux headers is fragile and >>> will break differently across the different linux >>> libc implementations. >> >> We saw this all the time working in embedded. >=20 > Do you mean you saw problems while you working in the embedded space? =20 Yes, embedded Linux to be specific. There is a strong coupling between the kernel version and the toolchain version, specifically because the strategies we take to solve these problems end up being brittle in this regard. Too new a kernel and you get new header problems not solved by your old libc. Too new a libc and the kernel doesn't have the header coordination fixes required for the newer software that needed the newer libc. Does that clarify my point? --=20 Cheers, Carlos.