Alexander Graf <ag...@suse.de> wrote: > But looking through this whole thing, it seems like the root cause is > actually different. We don't want any uapi directories exposed to user > space. So let's go back a step: > > Why do we need the uapi include dir? Because some header is using it. > > linux-headers/asm-powerpc/kvm_para.h: > > #include <uapi/asm/epapr_hcalls.h> > > This is the root cause of the problem. We must never manually include any > uapi header paths. We only ever include their normal asm-counterparts which > then may include uapi (in kernel) or actually are uapi (in user > space). David, please correct me if I'm wrong.
I think you're correct, if I understand what you're saying. Within the kernel sources, the userspace facing headers are in uapi/ directories whilst the stuff userspace shouldn't see is outside of that. uapi/ headers should _not_ #include headers with uapi/ prefixes; rather they should rely on the -I flags to pull in the UAPI header if the KAPI header of the same name does not exist. However, KAPI headers that shadow UAPI headers (linux/fs.h for example) _must_ manually #include the UAPI header with the uapi/ prefix as there's no other way to reach it. I originally used #include_next for this, but some people refused to countenance it because it's a gcc-ism, but no matter. After doing make headers_install in the kernel, you should find the contents of the appropriate uapi/ directories installed in the target directory without any uapi/ directories present. Further, the _UAPI prefixes on the guards are removed if present. There should be no #includes with "uapi/" in their filenames. David
