The UAPI header file split [LWN.net]

The UAPI header file split

Posted Jul 26, 2012 15:19 UTC (Thu) by dhowells (subscriber, #55933)
In reply to: The UAPI header file split by krisis
Parent article: The UAPI header file split

> The UAPI files seem to include the kernel headers.

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.

(Log in to post comments)

The UAPI header file split

Posted Jul 26, 2012 20:03 UTC (Thu) by krisis (subscriber, #70792) [Link]

What I was getting at, was that you could use this refactoring to get rid of some implicit includes and reduce the compile time.

After thinking about it, I've realized that it would be a massive undertaking, added to the already massive undertaking that this patch series is.