diff mbox

warn about use of uninstalled kernel headers

Message ID 200909211637.12983.arnd@arndb.de (mailing list archive)
State New, archived
Headers show

Commit Message

Arnd Bergmann Sept. 21, 2009, 2:37 p.m. UTC
On Friday 18 September 2009, Sam Ravnborg wrote:
> > > I think we should no longer have the include2 directory at all with new kernels.
> > >
> > > LINUXINCLUDE already contains the right path in theory:
> > >
> > > LINUXINCLUDE    := -Iinclude \
> > >                   $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
> > >                   -I$(srctree)/arch/$(hdr-arch)/include               \
> > >                   -include include/linux/autoconf.h
> > 
> > Hmm, at least in mmotm, we still have include2...
> > 
> > Maybe Sam is queueing the patches to remove include2?
> I have them queued - yes.
> But as they never hit -next they will wait another cycle.

Variations of this are starting to turn into a FAQ. How about
printing a useful warning when someone tries to use the kernel
headers without installing them first?

	Arnd <><
---
User applications frequently hit problems when they try to use
the kernel headers directly, rather than the exported headers.

This adds an explicit warning for this case, and points to
a URL holding an explanation of why this is wrong and what
to do about it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/linux/kernel.h     |    6 ++++++
 scripts/headers_install.pl |    2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Arnd Bergmann Sept. 22, 2009, 1:09 p.m. UTC | #1
On Tuesday 22 September 2009, Sam Ravnborg wrote:
> > +#ifndef __EXPORTED_HEADERS__
> But why do we need this "__EXPORTED_HEADERS__" thing?
> 
> ?

The problem is that the warning should only be for headers
that are not installed yet, but it needs to be stripped
in the installed version. Since we're already postprocessing
all files with unifdef, that seemed like the easiest way 
to strip out the #warning. Obviously, I couldn't use the
#ifdef __KERNEL__ logic, because that would either warn
give false positives when building kernel code or when
building user code from installed headers.

	Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d6320a3..f392d72 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -656,6 +656,12 @@  extern int do_sysinfo(struct sysinfo *info);
 
 #endif /* __KERNEL__ */
 
+#ifndef __EXPORTED_HEADERS__
+#ifndef __KERNEL__
+#warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders
+#endif /* __KERNEL__ */
+#endif /* __EXPORTED_HEADERS__ */
+
 #define SI_LOAD_SHIFT	16
 struct sysinfo {
 	long uptime;			/* Seconds since boot */
diff --git a/scripts/headers_install.pl b/scripts/headers_install.pl
index c6ae405..b89ca2c 100644
--- a/scripts/headers_install.pl
+++ b/scripts/headers_install.pl
@@ -20,7 +20,7 @@  use strict;
 
 my ($readdir, $installdir, $arch, @files) = @ARGV;
 
-my $unifdef = "scripts/unifdef -U__KERNEL__";
+my $unifdef = "scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__";
 
 foreach my $file (@files) {
 	local *INFILE;