lkml.org 
[lkml]   [2012]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: linux-next: build failure after merge of the staging tree
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> 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.


\
 
 \ /
  Last update: 2012-02-16 22:53    [W:0.047 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site