Re: Continuing the UAPI split

[Carlos O'Donell <carlos@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.