From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Re: Continuing the UAPI split Date: Fri, 08 Nov 2019 08:28:02 +0100 Message-ID: <87sgmyvnct.fsf@mid.deneb.enyo.de> 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> <70a264b5-427f-fa6e-7f70-768724202d14@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org In-Reply-To: <70a264b5-427f-fa6e-7f70-768724202d14@redhat.com> (Carlos O'Donell's message of "Thu, 7 Nov 2019 17:32:01 -0500") To: Carlos O'Donell Cc: Szabolcs Nagy , Elichai Turkel , nd , Christian Brauner , "linux-api@vger.kernel.org" , libc-alpha List-Id: linux-api@vger.kernel.org * Carlos O'Donell: > On 11/7/19 3:32 PM, Florian Weimer wrote: >> * Carlos O'Donell: >> >>> 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. >> >> Do you mean you saw problems while you working in the embedded space? > > 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? Yes, it does. It wasn't clear to me if you wanted to say that this was actually working for the embedded case.