should include/uapi include header files *unused* in kernel space?
was perusing the UAPI content in the kernel source, prepping for a course i'm teaching tomorrow, and just noticed there is a header file: $ find . -name mtd-user.h ./include/uapi/mtd/mtd-user.h $ which appears to be *entirely* unreferenced in the entire kernel code base (outside of the Kbuild file that refers to it): $ grep -r 'mtd-user.h' * include/uapi/mtd/Kbuild:header-y += mtd-user.h $ does this make any sense? am i missing something here? i would have thought that if a header file includes content that is wholly used exclusively in user space, it would be part of a package like "mtd-devel", or something like that. is this just for convenience to keep all the mtd stuff in the same place? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Sun, Jan 22, 2017 at 6:18 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
was perusing the UAPI content in the kernel source, prepping for a course i'm teaching tomorrow, and just noticed there is a header file:
$ find . -name mtd-user.h ./include/uapi/mtd/mtd-user.h $
which appears to be *entirely* unreferenced in the entire kernel code base (outside of the Kbuild file that refers to it):
$ grep -r 'mtd-user.h' * include/uapi/mtd/Kbuild:header-y += mtd-user.h $
Someone has a patch to remove msr-index.h which, in a similar way, only ended up being exported because of a Kbuild rule. So I'd imagine this file would be a candidate for a similar patch. https://lkml.org/lkml/2017/2/2/228. -- Jim
On Fri, 3 Feb 2017, Jim Davis wrote:
On Sun, Jan 22, 2017 at 6:18 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
was perusing the UAPI content in the kernel source, prepping for a course i'm teaching tomorrow, and just noticed there is a header file:
$ find . -name mtd-user.h ./include/uapi/mtd/mtd-user.h $
which appears to be *entirely* unreferenced in the entire kernel code base (outside of the Kbuild file that refers to it):
$ grep -r 'mtd-user.h' * include/uapi/mtd/Kbuild:header-y += mtd-user.h $
Someone has a patch to remove msr-index.h which, in a similar way, only ended up being exported because of a Kbuild rule. So I'd imagine this file would be a candidate for a similar patch. https://lkml.org/lkml/2017/2/2/228.
i'm not sure we're talking about the same situations here. in the case you mention, it appears that msr-index.h could be dropped from exporting since (i'm assuming) nothing in user space needs it. but it's still included from several places in kernel space: $ grep -r "msr-index.h" * arch/x86/realmode/rm/wakeup_asm.S:#include <asm/msr-index.h> arch/x86/realmode/rm/reboot.S:#include <asm/msr-index.h> arch/x86/xen/enlighten.c:#include <asm/msr-index.h> arch/x86/boot/cpuflags.c:#include <asm/msr-index.h> arch/x86/boot/cpucheck.c:#include <asm/msr-index.h> arch/x86/kernel/verify_cpu.S:#include <asm/msr-index.h> arch/x86/kernel/head_32.S:#include <asm/msr-index.h> ... etc etc ... $ so, in this case, that header file is still useful in kernel space and must be kept. in the case *i* mention (mtd-user.h), it appears that that header file *does* need to exist in user space, but it is totally unused in kernel space: $ grep -r "mtd-user.h" * include/uapi/mtd/Kbuild:header-y += mtd-user.h $ in cases like this, is it really appropriate for that header file to exist in kernel space when nothing in kernel space includes it? yes, i appreciate the convenience of having all those mtd-related header files defined in one place; i'm just curious about what the standard practice is for kernel space defining header files it has no need for. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
participants (2)
-
Jim Davis -
Robert P. J. Day