(again, apologies for whinging on so much about the pedantics of
UAPI and header files, if there's a more appropriate forum, by all
means, let me know.)
sort of another followup to my last post -- under what circumstances
is it appropriate to *explicitly* include a UAPI header file?
the first scenario is the obvious one; if a kernel header file has
been refactored into two parts, then of course the "kernel space"
version will want to include the corresponding "user space" version,
as in:
* include/linux/derp.h
...
#include <uapi/linux/derp.h>
...
* include/uapi/linux/derp.h
where the kernel space version should (theoretically) be completely
free of user space-only content, but the user space version might
still contain some kernel space content that was too much trouble to
remove, but will still be sanitized by the export process. so far, so
good?
the other obvious situation for including uapi/ header files is in
actual user space code, like under the tools/ directory that is
specifically meant for building in user space, such as this under
tools/:
perf/tests/bpf-script-test-prologue.c:#include <uapi/linux/fs.h>
perf/tests/bpf-script-test-kbuild.c:#include <uapi/linux/fs.h>
perf/tests/bpf-script-test-kbuild.c:#include <uapi/asm/ptrace.h>
which brings up an obvious question: other than those two situations,
is there any *other* rationale for kernel code to be explicitly
including uapi/ header files?
consider this example in drivers/input/serio/userio.c:
...
#include <linux/miscdevice.h>
#include <linux/sched.h>
#include <linux/poll.h>
#include <uapi/linux/userio.h> <----- ?????
...
why would kernel code do that? in this situation, there is only one
userio.h header file in the entire tree -- that one -- so it would
have been equivalent to just write:
#include <linux/userio.h>
it seems even stranger when you *do* have a kernel/user space split
of a header file, as in:
* include/linux/virtio_ring.h
#include <uapi/linux/virtio_ring.h>
* include/uapi/linux/virtio_ring.h
so you would expect kernel code to include the first one, no? and yet,
in include/linux/vringh.h, you see:
#include <uapi/linux/virtio_ring.h>
that confuses me ... why would kernel space content explicitly pull
in a header file from include/uapi/, effectively bypassing the kernel
content in the regular include directory?
thoughts?
rday
p.s. oh, crap, i just noticed that the example header file i used
above, include/uapi/linux/userio.h, isn't even exported to user space;
it exists only in that uapi/ directory, it's not listed for export in
include/uapi/linux/Kbuild, and it's only include references in the
entire tree are:
$ grep -r "include.*userio.h" *
drivers/input/serio/userio.c:#include <uapi/linux/userio.h>
MAINTAINERS:F: include/uapi/linux/userio.h
$
so now i'm totally confused. even the doc file for that,
Documentation/input/userio.txt, refers to that header file thusly:
"All of the structures and macros you need to interact with the device
are defined in <linux/userio.h> and <linux/serio.h>."
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
