* 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
