is there a strong (or even weak) style recommendation when including kernel header files under include/uapi in terms of explicitly including the "uapi" path component? i'm fully aware of the standard that most kernel code should include the "standard" kernel headers, such as: #include <linux/mii.h> where those headers are, of course, free to turn around and include the corresponding UAPI content; the above header file does indeed do just that: #include <linux/if.h> #include <uapi/linux/mii.h> however, in that very example, you can see the include of "linux/if.h" where there is, in fact, no header file include/linux/if.h, only include/uapi/linux/if.h. i can see from the top-level Makefile that that include will eventually pick up the UAPI version of the if.h header file: # Use USERINCLUDE when you must reference the UAPI directories only. USERINCLUDE := \ -I$(srctree)/arch/$(SRCARCH)/include/uapi \ -I$(objtree)/arch/$(SRCARCH)/include/generated/uapi \ -I$(srctree)/include/uapi \ -I$(objtree)/include/generated/uapi \ -include $(srctree)/include/linux/kconfig.h # Use LINUXINCLUDE when you must reference the include/ directory. # Needed to be compatible with the O= option LINUXINCLUDE := \ -I$(srctree)/arch/$(SRCARCH)/include \ -I$(objtree)/arch/$(SRCARCH)/include/generated \ $(if $(KBUILD_SRC), -I$(srctree)/include) \ -I$(objtree)/include \ $(USERINCLUDE) the point is, is that acceptable style? when i'm perusing kernel code and i see a reference to a header file <linux/if.h>, i simply assume it's a standard header file under include/, and i expect header files under the UAPI directory will explicitly say so in the include directive. thoughts? rday