linux-kernel - Re: linux-next: build failure after merge of the akpm tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 24 Oct 2012 12:38:42 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Joe Perches <joe@...ches.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Kay Sievers <kay@...y.org>
Subject: Re: linux-next: build failure after merge of the akpm tree

On Wed, 24 Oct 2012 12:19:39 -0700
Joe Perches <joe@...ches.com> wrote:

> On Tue, 2012-10-23 at 13:02 -0700, Andrew Morton wrote:
> > On Tue, 23 Oct 2012 12:51:29 -0700
> > Joe Perches <joe@...ches.com> wrote:
> > 
> > > > 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.


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