Re: Continuing the UAPI split

[Florian Weimer <fweimer@redhat.com>]

* Elichai Turkel:

> Thanks for the response,
> I'm not sure what are you suggesting exactly.
> A rename to the structs/types so they won't collide with libc?

Or use namespaces.  I mean, we have had proper technical solutions for
this issue for more than 20 years now.  I know that this isn't going to
happen, though.

> Prioritizing POSIX conformance in the kernel(I think that ship has long sailed)?

That doesn't really work anyway if userspace has different versions of
the type depending on feature macros.  Examples are struct stat or soon
struct timespec on 32-bit architectures.

> Or just giving up and telling users they can't just directly include
> both libc headers and kernel headers?

That's what I've been telling users if they encounter fringe cases I
can't fix on the glibc side.

It might also help if top-level types for end user use would be in
separate headers.  This is what we started doing internally in glibc, to
disentangle our own headers and eliminate cyclic dependencies.

> (I'm actually not sure how it works now. because there are definitely
> collision and if we are using ifdefs and undefs black magic you still
> end up with a single declaration in the end that might not be
> compatible with both libc and kernel)

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.

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.

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.

Thanks,
Florian