On Mon, Jun 01, 2015 at 11:08:21AM +0200, Christian König wrote:In this case I'm fine with the changes, but I'm still not sure if that's a good idea or not.
Yeah, completely agree with Linus on the visibility problem and that's1) Header files are permitted to pollute userspace with __-defined stuff.
exactly the reason why we don't include <stdint.h> in the kernel header and
expect userspace to define the ISO types somewhere.
But using the types from "include/linux/types.h" and especially including it
into the uapi headers doesn't make the situation better, but rather worse.
With this step we not only make the headers depend on another header that
isn't part of the uapi, but also pollute the user space namespace with __sXX
and __uXX types which aren't defined anywhere else.
2) __[su]XX types are defined as part of the kernel's uapi.
include/uapi/linux/types.h includes asm/types.h, which in userspace
picks up include/uapi/asm-generic/types.h. That picks up
asm-generic/int-ll64.h, which defines these types.
Moreover, this is done throughout the kernel headers _already_ (as you
would expect for a policy set 10+ years ago).
Please, I'm not interested in this discussion, so please don't argue
with me - I may agree with your position, but what you think and what
I think are really not relevant here. If you have a problem, take it
up with Linus - I made that clear in my email.