On Wed, 24 Oct 2012 12:19:39 -0700
Joe Perches [off-list ref] wrote:

On Tue, 2012-10-23 at 13:02 -0700, Andrew Morton wrote:

quoted

On Tue, 23 Oct 2012 12:51:29 -0700
Joe Perches [off-list ref] wrote:

quoted

quoted

btw, what's up with printk_syslog.h?  It includes two header files which it
doesn't need but fails to include the two it *does* need: printk_log.h
and types.h.

printk_syslog.c includes kernel.h (it includes types.h)
and printk_log.h.

I think printk_syslog.h doesn't need printk_log.h

A general rule is that the header file shouldn't know or care what else
it's includer has included.  Ideally it shouldn't know or care what
else its includees have included, either.

A fun test would be

for i in *.h
	echo $i > foo.c
	make foo.o
done

A whole lot of things in include/ fail this.

I bet.

Do you really think that anything using u8/16/32/64
should include types.h?

Well, yes.  If someone writes a C file which includes such a header as
fisst-included then OK, it will fail and they'll fix things up.  But
where the problems occur is when that file is *not* the first-included,
but they happened to get types.h via another Kconfig-dependent include.
Later, the build explodes for someone else.  The only reliable way of
avoiding this is for each file to include its dependencies.

I don't think it's worth going off and trying to "fix" all of this
though.  Such an exercise has its own risks and this problem just isn't
that big - it happens often enough, but it's very easy to fix.