[Ksummit-discuss] Should .c files be discouraged from #including UAPI headers directly?

[Ksummit-discuss] Should .c files be discouraged from #including UAPI headers directly?

[David Howells]

Is it okay for ordinary .c files to #include uapi/ files directly?

	warthog>git grep 'include.*uapi/' -- \*.c
	arch/arm/kernel/psci.c:#include <uapi/linux/psci.h>
	arch/arm/kernel/psci_smp.c:#include <uapi/linux/psci.h>
	arch/arm64/kernel/psci.c:#include <uapi/linux/psci.h>
	arch/blackfin/kernel/setup.c:#include <uapi/linux/cramfs_fs.h>
	arch/mips/bcm63xx/boards/board_bcm963xx.c:#include <uapi/linux/bcm933xx_hcs.h>
	arch/mips/pci/pci-virtio-guest.c:#include <uapi/asm/bitfield.h>
	arch/x86/vdso/vclock_gettime.c:#include <uapi/linux/time.h>
	arch/xtensa/kernel/syscall.c:#include <uapi/asm/unistd.h>
	drivers/gpu/drm/exynos/exynos_drm_fb.c:#include <uapi/drm/exynos_drm.h>
	drivers/infiniband/core/sa_query.c:#include <uapi/linux/if_ether.h>
	drivers/mtd/ar7part.c:#include <uapi/linux/magic.h>
	...

or should they be encouraged to #include the non-uapi variant instead, eg:

	#include <linux/psci.h>

rather than:

	#include <uapi/linux/psci.h>

given that appropriate -I flags are supplied such that they'll fall back to
the UAPI header if a kernel-internal header does not exist?

David

Re: [Ksummit-discuss] Should .c files be discouraged from #including UAPI headers directly?

[Greg KH]

On Wed, Aug 06, 2014 at 12:28:43PM +0100, David Howells wrote:
> Is it okay for ordinary .c files to #include uapi/ files directly?
> 
> 	warthog>git grep 'include.*uapi/' -- \*.c
> 	arch/arm/kernel/psci.c:#include <uapi/linux/psci.h>
> 	arch/arm/kernel/psci_smp.c:#include <uapi/linux/psci.h>
> 	arch/arm64/kernel/psci.c:#include <uapi/linux/psci.h>
> 	arch/blackfin/kernel/setup.c:#include <uapi/linux/cramfs_fs.h>
> 	arch/mips/bcm63xx/boards/board_bcm963xx.c:#include <uapi/linux/bcm933xx_hcs.h>
> 	arch/mips/pci/pci-virtio-guest.c:#include <uapi/asm/bitfield.h>
> 	arch/x86/vdso/vclock_gettime.c:#include <uapi/linux/time.h>
> 	arch/xtensa/kernel/syscall.c:#include <uapi/asm/unistd.h>
> 	drivers/gpu/drm/exynos/exynos_drm_fb.c:#include <uapi/drm/exynos_drm.h>
> 	drivers/infiniband/core/sa_query.c:#include <uapi/linux/if_ether.h>
> 	drivers/mtd/ar7part.c:#include <uapi/linux/magic.h>
> 	...
> 
> or should they be encouraged to #include the non-uapi variant instead, eg:
> 
> 	#include <linux/psci.h>
> 
> rather than:
> 
> 	#include <uapi/linux/psci.h>
> 
> given that appropriate -I flags are supplied such that they'll fall back to
> the UAPI header if a kernel-internal header does not exist?

Why does it matter?  What works "better" if a .c file doesn't include
the uapi.h file?

thanks,

greg k-h

Re: [Ksummit-discuss] Should .c files be discouraged from #including UAPI headers directly?

[Jamal Hadi Salim]

On 08/06/14 10:45, Greg KH wrote:
> On Wed, Aug 06, 2014 at 12:28:43PM +0100, David Howells wrote:
>
>>
>> 	#include <uapi/linux/psci.h>
>>
>> given that appropriate -I flags are supplied such that they'll fall back to
>> the UAPI header if a kernel-internal header does not exist?
>
> Why does it matter?  What works "better" if a .c file doesn't include
> the uapi.h file?
>


IMO, it is more intuitive to have an explicit uapi/
Issue i came across recently:
Old tutorials floating around specify a tc action module should
stash the user header in linux/tc_act - which would work
given current makefiles; but that is not what we want them to do
given iproute2 picks headers off uapi/linux
We cant fix old floating tutorials but by fixing the code to point
to the correct header location we are essentially documenting.

cheers,
jamal

Re: [Ksummit-discuss] Should .c files be discouraged from #including UAPI headers directly?

[David Howells]

Greg KH <greg@kroah.com> wrote:

> Why does it matter?  What works "better" if a .c file doesn't include
> the uapi.h file?

Some of the UAPI headers are 'fixed up' by the non-UAPI header.  In
linux/types.h, for example:

	#define __EXPORTED_HEADERS__
	#include <uapi/linux/types.h>

and linux/acct.h:

	#include <uapi/linux/acct.h>
	...
	#undef ACCT_VERSION
	#undef AHZ

and linux/quota.h:

	#include <uapi/linux/quota.h>
	...
	#undef USRQUOTA
	#undef GRPQUOTA

I don't now remember where they all are:-/

David