RE: linux-next: build failure after merge of the staging tree

[Dan Magenheimer]

> From: Stephen Rothwell [mailto:sfr@xxxxxxxxxxxxxxxx]
> Subject: Re: linux-next: build failure after merge of the staging tree
> 
> Hi Dan,

Hi Stephen --

Thanks for the reply and sorry for the hassle.  See below for
important question.

> > which changed the names of those fields from "flush*" to "invalidate*".
> > I am the author of that commit but it is pulled through Konrad Wilk
> > (cc'ed). Perhaps Konrad's pull succeeded in next-20120214 but
> > failed in next-20120215?
> 
> If a fetch fails for a particular tree on a particular day, I use the
> version of that tree from the day before, so that is not the problem (and
> in any case, the fetch did not fail).
> 
> > Kernel.org seems to be down so I can't see if that commit is
> > in next-20120215 but if it is not that would likely cause
> > the above errors.
> 
> It is in next-20120215 (and has been since next-20120124).  However, I
> merge Konrad's (tmem) tree *after* I merge the staging tree, so that commit
> was not present when I tried to build linux-next after merging the
> staging tree.

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?)
 
> > The good news is that there seems to be an increasing number
> > of people contributing to and building things on top of
> > cleancache/frontswap stuff.  The bad news is that it is difficult
> > to avoid ordering dependencies that affect -next.  My apologies
> > and if you have any dependency-savvy processes that would solve
> > this that we are not using, please let me/us know.
> 
> Well, if anyone had bothered to tell me, I could have reordered the
> trees.  However, that does not change the fact that the staging tree is
> now broken on its own.  Which means that Greg can't even do unit testing
> on his tree with your code in it. :-(

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.**

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

> One solutions is for Greg to merge Konrad's tree (or a subset of it) into
> the staging tree.  Another is for this work to become a separate tree
> (however, I think other stuff in the staging tree depends on this work,
> right?).

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.

Thanks,
Dan

** I just found another problem that occurs with allmodconfig
so will be submitting a patch for that to GregKH shortly and
will cc you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/