linux-kernel - Re: [RFC - PATCH 0/7] consolidation of BUG support code.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120127192354.GA7150@windriver.com>
Date:	Fri, 27 Jan 2012 14:23:55 -0500
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
CC:	<torvalds@...ux-foundation.org>, <akpm@...ux-foundation.org>,
	<gregkh@...e.de>, <rmk+kernel@....linux.org.uk>,
	<linux-arch@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC - PATCH 0/7] consolidation of BUG support code.

[Re: [RFC - PATCH 0/7] consolidation of BUG support code.] On 27/01/2012 (Fri 16:52) Stephen Rothwell wrote:

> Hi Paul,
> 
> On Thu, 26 Jan 2012 21:44:25 -0500 Paul Gortmaker <paul.gortmaker@...driver.com> wrote:
> >
> > The changes shown here are to unify linux's BUG support under
> > the one <linux/bug.h> file.  Due to historical reasons, we have
> > some BUG code in bug.h and some in kernel.h -- i.e. the support for
> > BUILD_BUG in linux/kernel.h predates the addition of linux/bug.h,
> > but old code in kernel.h wasn't moved to bug.h at that time.  As
> > a band-aid, kernel.h was including <asm/bug.h> to pseudo link them.
> > With the above in mind, the goals of this changeset are:
> > 
> > 1) find and fix any include/*.h files that were relying on the
> >    implicit presence of BUG code.
> > 2) find and fix any C files that were consuming kernel.h and
> >    hence relying on implicitly getting some/all BUG code.
> > 3) Move the BUG related code living in kernel.h to <linux/bug.h>
> > 4) remove the asm/bug.h from kernel.h to finally break the chain.
> > 
> > During development, the order was more like 3-4, build-test, 1-2.
> > But to ensure that git history for bisect doesn't get needless
> > build failures introduced, the commits have been reorderd to fix
> > the problem areas in advance.
> 
> I have expressed reservations with these tree wide include file cleanups
> in the past (there was going pain for me and others during the module.h

Well, I thought module.h went reasonably OK for something that touched
close to 2500 files.  I don't recall getting a lot of scorn and flame.
In any case, this is nowhere near that size or scope of the module.h
work, so I'll go out on a limb and say it should be nearly "pain free".

> split up for example).  So, have you considered the following alternate

> method of achieving most (if not all) of the gains:
> 
> First a patch that moves the BUG related stuff from kernel.h to
> linux/bug.h and replacing the include of asm/bug.h with linux/bug.h in
> kernel.h.  This should essentially be a noop (bar some strange
> interesting bugs).

You don't even really need the above as a prerequisite in order to start
adding bug.h to all the places that are using it.  As I noted in one of
the commit logs, things are compiling today, so files using BUG are
already getting it one way or another -- just implicitly.

> 
> The trick is to convince Linus that this patch is OK for the current RC series ...
> 
> Then you can (at your leisure) fix all the files that need linux/bug.h
> included - farming them out as required.  And we could add a check in
> checkpatch.pl.

I originally had the module.h stuff broken across maintainer lines, as
I was assuming they would need to be farmed out as chunks, when Ingo
suggested to just lump it all into one pull request and have it go at
once (and I was fine with that).  So this time I didn't bother making
things like the one include/* commit into 60-odd separate commits.

I'm not really inclined to greatly favour one way over the other.
Tracking all the one line commits to make sure they make it through
the various sub-maintainers will take a bit more effort, but if that
is what folks *really* want me to do, I'm OK with that.  It is just
that your feedback here is the 1st I've heard favouring that method
so far.

Thanks,
Paul.

> 
> Then (either after 3.4-rc1 or in the 3.5 merge window) we can remove the
> include of linux/bug.h from linux/kernel.h and fix any left over build
> problems.
> 
> I have not thought about this too hard, so there may be large holes in
> this plan.
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@...b.auug.org.au


--
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/