Yes. That is so - *if* you're using them for a kernel build. If you're using them for a userspace build, they only see each other.
It actually mirrors the way things work now. Just think of the way such kernel header files are usually constructed: a bunch of #includes that get put into the userspace header, then some userspace defs, then the __KERNEL__ guard, then the kernel space stuff.
With what I've constructed, it ends up being pretty much the same - except that the UAPI part of it is in a separate file.
> This seems unnecessary
Unfortunately, if I use uapi/ in the UAPI header files' #includes they will need processing to remove it on installation. The alternative would require the KAPI headers have different names in some way (either named something different or with different directory components) - they would have to be distinguished by cpp, right?
> and would make it possible to depend on declarations that are implicitly
> defined through the kernel versions of the header.
I'm not sure what you're getting at. #including a kernel header after the split must give you at least what you got from it before the split, even if some of those bits are obtained indirectly. I don't think there are any cases where you get anything more than you got before the split.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds