Re: Continuing the UAPI split

[Elichai Turkel <elichai dot turkel at gmail dot com>]

On Thu, Nov 7, 2019 at 2:10 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> The kernel uses some POSIX names with POSIX-incompatible definitions,
> e.g. struct msghdr.  Some libcs prioritize POSIX conformance over kernel
> conformance and implement userspace translation for mismatch types.
> When building against such libcs, it becomes difficult to use UAPI and
> libc headers in a single translation unit.  (It is already difficult
> today in some cases.)
>
> I don't know a good solution here.  Not using POSIX names in UAPI
> headers is one option.  Previously, we have tried to use preprocessor
> macros to coordinate definitions, but did not work well in practice
> (only few conflicts were ever resolved).  It does not help at all when
> the definitions are incompatible.
>
> Thanks,
> Florian
>

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?
Prioritizing POSIX conformance in the kernel(I think that ship has long sailed)?
Or just giving up and telling users they can't just directly include
both libc headers and kernel headers?
(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)

I'd personally really like to see a better separation between (g)libc
and the kernel. I

Thanks,
Elichai.

-- 
PGP: 5607C93B5F86650C