This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Continuing the UAPI split
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Elichai Turkel <elichai dot turkel at gmail dot com>
- Cc: Christian Brauner <christian dot brauner at ubuntu dot com>, linux-api at vger dot kernel dot org, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 7 Nov 2019 13:02:18 -0500
- Subject: Re: Continuing the UAPI split
- References: <CALN7hCK0EXLXjPRPr+tuuF2-uQvkLMCFDNzGhv9HS-jrAz6Hmg@mail.gmail.com> <0B17C6F2-DC2B-4192-B4AD-BD11D6B9F2B6@ubuntu.com> <87zhh7j38y.fsf@oldenburg2.str.redhat.com> <CALN7hCJ_umFqC1L0T19CuiGiGoVwac5807NDw4LiDqSD-VJL=Q@mail.gmail.com> <87zhh7hlbl.fsf@oldenburg2.str.redhat.com>
On 11/7/19 8:23 AM, Florian Weimer wrote:
> Officially, it's supposed to work today. We have one glibc developer
> who says that it's easy to solve, but I disagree strongly. The fact
> that the problems are not fixed promptly suggests that it's anything but
> simple.
Is that one glibc developer me? :-)
They aren't easy to solve, but there is a magic process in place.
Getting the definitions to line up is part of the work involved.
Sometimes they may not line up, in that case it doesn't work.
> What I've been doing instead is to include UAPI headers directly from
> glibc headers if it's technically feasible. (It's not possible in POSIX
> mode, where we have to manage the set of exported symbols closely, or
> generally with old compilers which do not have __has_include.) See
> <bits/statx.h>, <bits/statx-generic.h> etc. in current glibc for an
> example.
That's really the best way to solve it if you can.
> If you add more type definitions to kernel headers, this might interfere
> with such usage of UAPI headers because today, we need to provide our
> own definitions for many things not in UAPI headers, and the currently
> deployed glibc headers are simply not compatible with such future
> changes.
Right.
--
Cheers,
Carlos.