linux-kernel - Re: linux-next: build failure after merge of the staging 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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20120217103917.36721f3e8f75c35092c2dce2@canb.auug.org.au>
Date:	Fri, 17 Feb 2012 10:39:17 +1100
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
Cc:	Greg KH <greg@...ah.com>, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org, Konrad Wilk <konrad.wilk@...cle.com>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Nitin Gupta <ngupta@...are.org>
Subject: Re: linux-next: build failure after merge of the staging tree

Hi Dan,

On Thu, 16 Feb 2012 13:49:53 -0800 (PST) Dan Magenheimer <dan.magenheimer@...cle.com> wrote:
>
> Huh?  Do you do allyesconfig/allmodconfig build testing after you pull
> each individual tree or only after all trees are pulled?  (Apparently
> the former, as otherwise the ordering shouldn't matter, right?)

From my daily release note:

"Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary."

So yes, I build between each merge.  It allows me to isolate where
problems are occurring so that they can be easily fixed in isolation.

> If you are doing the after-every-individual-tree build testing,
> yes, if you could pull konrad's tmem tree first, that would
> solve this problem I believe.**

Yes, I can do that (and will for today).  However, it does mean that the
staging tree now cannot be merged into Linus' tree until after the tmem
tree has been merged.   And if Linus decides not to take it, then Greg
will have to remove these commits from his tree (or revert them) before
he can get all the rest of the staging tree into Linus' tree.

> I suspect unit testing doesn't make much as much sense in staging
> as it does in the core kernel.  I did testing of ramster in my

Of course it makes sense - at least at the "make sure it builds" level.

> public git tree (which includes the tmem patchset coming to you via
> konrad) but, since it is a staging driver, the bits have to go
> through Greg.

Maybe you should seek a dispensation from Greg to allow your ramster tree
to exist independently in linux-next and be merged independently by
Linus'.  Greg may want to keep watch in your tree, but that should not be
much more effort than reviewing and applying your patches to the staging
tree.

> Yes, there are a number of parts from different companies/timezones
> now flying in close formation.  The name change (flush->invalidate)
> causing this problem was insisted upon by Andrew Morton (and has been
> in linux-next for several months), otherwise it wouldn't have happened
> and wouldn't be causing these issues :-(  But better to work through
> them in -next than in Linus' merge window I guess.

Definitely.

I do realise that the staging tree is "special", but I am trying to deal
with this in a generic manner (as I would for dependencies between any
other two trees).

-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au

Content of type "application/pgp-signature" skipped