Re: [patch 1/8] extend make headers_check to detect more problems

[Arnd Bergmann <arnd@arndb.de>]

On Saturday 23 September 2006 13:04, David Woodhouse wrote:
> It would be good to fix these problems, it's true -- but bear in mind
> that none of these are actually fatal problems -- they're just caveats
> of (ab)using kernel-private headers in userspace. 
> 
> On the other hand, it would be good to get people used to running
> 'make headers_check' whenever they make a change -- so introducing more
> breakage right now may be counterproductive from that point of view.
> 
> So I think I'd prefer to leave this for now, or at least limit it to
> 'make CHECKMEHARDER=1 headers_check' so that we can wean people onto
> using headers_check slowly and relatively painlessly.

yes, that sounds fair.

> > I found many problems with this, which I then fixed for
> > powerpc, s390 and i386, in subsequent patches.
> 
> Can you -include <linux/types.h> _every_ time, to reduce the number of
> places you have to add '/* @headercheck: -include linux/types.h @ */' ?

The problem with this are a few files which have code like

#ifndef __KERNEL__
#include <sys/types.h>
#include <stdint.h>
#endif

or similar. These break heavily if you include <linux/types.h> before the
the glibc provided headers, because linux/types.h provides some of the
types that are normally defined elsewhere and duplicate typedefs result
in compile errors.

To solve this, we would need to make all headers build fine with
gcc -D__STRICT_KERNEL_NAMES -include linux/types.h.
That is a valueable goal as well, since it avoids a number of problems,
but it is actually a larger change than this.

Now one option we could take would be to always pass -include linux/types.h
to gcc and put /* @headercheck: -D__STRICT_KERNEL_NAMES */ into the few
places that break otherwise.

	Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/