LWN: Comments on "The UAPI header file split"

The UAPI header file split

anuj1560 — Mon, 04 Mar 2019 14:08:31 +0000

In file uapi/linux/i2c.h , it includes linux/types.h. Is this right ? I think it should include uapi/linux/types.h.

The UAPI header file split

marcH — Fri, 03 Aug 2012 13:15:15 +0000

> Sometimes, however, the sheer size of the code base means that refactoring becomes a formidable task—one that verges on being impossible if attempted manually. At that point, an enterprising kernel hacker may well turn to writing code that refactors the [kernel] code.

For Java such code has been written already: (at least) Eclipse does this on a routine basis.

Of course this is a much easier problem since Java has no pre-processor. I'm still impressed seeing it in action.

The UAPI header file split

jake — Sun, 29 Jul 2012 16:40:02 +0000

fixed now ...

jake

The UAPI header file split

ranmachan — Sat, 28 Jul 2012 17:39:01 +0000

Typo: "[Users-pace definitions]" slowed down for users who can't keep up with Kernels-pace. :)

Checking same object files produced

nix — Fri, 27 Jul 2012 11:17:43 +0000

Given that the only #defines this code should be altering are those related to multiple-inclusion guards, I think we could describe any such ordering changes as a compiler bug. That is not to say that no such bugs exist, but it is likely that they'd also lead to inconsistent code generation when faced with identical output, and cause failures in GCC bootstrap comparison. (This has happened before, e.g. with optimizations depending on the ordering of pieces of compiler state in hash tables -- the infamous 'hashing by
address' bug class -- and that sort of thing.)

The UAPI header file split

dlang — Fri, 27 Jul 2012 04:32:36 +0000

sounds like a good topic for discussion at the kernel summit.

The UAPI header file split

dhowells — Thu, 26 Jul 2012 20:30:08 +0000

This patch series is just step 1...

The UAPI header file split

krisis — Thu, 26 Jul 2012 20:03:28 +0000

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.

The UAPI header file split

dhowells — Thu, 26 Jul 2012 15:19:55 +0000

> 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.

Checking same object files produced

ms — Thu, 26 Jul 2012 12:28:18 +0000

Take the generated assembly before and after and prove it's equivalent? Yes, I'll fetch my coat...

The UAPI header file split

krisis — Thu, 26 Jul 2012 12:09:48 +0000

I took a quick look at this patch set, and I've found some weirdness that I'm not sure what to make of.

The UAPI files seem to include the kernel headers.
For example: the include/uapi/linux/eventpoll.h file includes <linux/fcntl.h>.

The include stack would then look like this for a kernel compile:

linux/eventpoll.h
uapi/linux/eventpoll.h
linux/fcntl.h
uapi/linux/fcntl.h
...
etc.

This seems unnecessary and would make it possible to depend on declarations that are implicitly defined through the kernel versions of the header.

Unless I'm mistaken. Which is a very likely possibility.

Checking same object files produced

NRArnot — Thu, 26 Jul 2012 11:39:21 +0000

That's assuming the compiler is perfectly well-behaved. It might be that the different ordering of #define statements changes the internal state of the compiler, leading to a change in the ordering of entities which are present in the generated code. The binary code would then be functionally identical but not byte-for-byte identical.

Checking same object files produced

epa — Thu, 26 Jul 2012 10:59:02 +0000

I imagine that rearranging some header files will not change the generated code. So the correctness check can be making sure that the resulting kernel image is byte-for-byte identical (for various sets of config flags). The review process then isn't to check correctness of each line of patch, but to approve the general idea.