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

[Dan Magenheimer]

> From: Greg KH [mailto:greg@xxxxxxxxx]
> Subject: Re: linux-next: build failure after merge of the staging tree
> 
> On Thu, Feb 16, 2012 at 03:23:16PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/staging/ramster/zcache-main.c:2969:2: error: unknown field 'invalidate_page' specified in
> initializer
> > drivers/staging/ramster/zcache-main.c:2970:2: error: unknown field 'invalidate_inode' specified in
> initializer
> > drivers/staging/ramster/zcache-main.c:2971:2: error: unknown field 'invalidate_fs' specified in
> initializer
> >
> > I do wonder if any of this was build tested with CONFIG_CLEANCACHE enabled ...

Absolutely, against next-20120214, which contained commit

91c6cc9b5c216bd067f9af2cc64fcbe190755865

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?

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.

> > Caused by commit 19ee3ef5f4bb ("staging: ramster: local compression + tmem").
> >
> > I have used the staging tree from next-20120215 for today.
> 
> Dan, can you please fix this?

Hmmm... moving target.  I'm trying to get in touch with Konrad
to see if we can determine what is going on.

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