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:2969:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/staging/ramster/zcache-main.c:2969:2: warning: (near initialization for 'zcache_cleancache_ops.put_page') [enabled by default]
drivers/staging/ramster/zcache-main.c:2970:2: error: unknown field 'invalidate_inode' specified in initializer
drivers/staging/ramster/zcache-main.c:2970:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/staging/ramster/zcache-main.c:2970:2: warning: (near initialization for 'zcache_cleancache_ops.flush_page') [enabled by default]
drivers/staging/ramster/zcache-main.c:2971:2: error: unknown field 'invalidate_fs' specified in initializer
drivers/staging/ramster/zcache-main.c:2971:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/staging/ramster/zcache-main.c:2971:2: warning: (near initialization for 'zcache_cleancache_ops.flush_inode') [enabled by default]
drivers/staging/ramster/zcache-main.c:913:13: warning: 'zcache_do_remotify_ops' defined but not used [-Wunused-function]
drivers/staging/ramster/zcache-main.c:1002:13: warning: 'ramster_remotify_init' defined but not used [-Wunused-function]
I do wonder if any of this was build tested with CONFIG_CLEANCACHE enabled ...
Caused by commit 19ee3ef5f4bb ("staging: ramster: local compression + tmem").
I have used the staging tree from next-20120215 for today.
--
Cheers,
Stephen Rothwell [email protected]
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:2969:2: warning: initialization from incompatible pointer type [enabled by default]
> drivers/staging/ramster/zcache-main.c:2969:2: warning: (near initialization for 'zcache_cleancache_ops.put_page') [enabled by default]
> drivers/staging/ramster/zcache-main.c:2970:2: error: unknown field 'invalidate_inode' specified in initializer
> drivers/staging/ramster/zcache-main.c:2970:2: warning: initialization from incompatible pointer type [enabled by default]
> drivers/staging/ramster/zcache-main.c:2970:2: warning: (near initialization for 'zcache_cleancache_ops.flush_page') [enabled by default]
> drivers/staging/ramster/zcache-main.c:2971:2: error: unknown field 'invalidate_fs' specified in initializer
> drivers/staging/ramster/zcache-main.c:2971:2: warning: initialization from incompatible pointer type [enabled by default]
> drivers/staging/ramster/zcache-main.c:2971:2: warning: (near initialization for 'zcache_cleancache_ops.flush_inode') [enabled by default]
> drivers/staging/ramster/zcache-main.c:913:13: warning: 'zcache_do_remotify_ops' defined but not used [-Wunused-function]
> drivers/staging/ramster/zcache-main.c:1002:13: warning: 'ramster_remotify_init' defined but not used [-Wunused-function]
>
> I do wonder if any of this was build tested with CONFIG_CLEANCACHE enabled ...
>
> 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?
greg k-h
> From: Greg KH [mailto:[email protected]]
> 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.
Hi Dan,
On Thu, 16 Feb 2012 06:39:42 -0800 (PST) Dan Magenheimer <[email protected]> wrote:
>
> > From: Greg KH [mailto:[email protected]]
> > 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?
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.
> > > 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.
See above.
> 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. :-(
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?).
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
> From: Stephen Rothwell [mailto:[email protected]]
> 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.
Hi Dan,
On Thu, 16 Feb 2012 13:49:53 -0800 (PST) Dan Magenheimer <[email protected]> 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 [email protected]
On Fri, Feb 17, 2012 at 10:39:17AM +1100, Stephen Rothwell wrote:
> Hi Dan,
>
> On Thu, 16 Feb 2012 13:49:53 -0800 (PST) Dan Magenheimer <[email protected]> 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.
Ick, no, I'll just mark this as CONFIG_BROKEN for now, and things can be
fixed up later, during the 3.4 window as it should all settle down then.
thanks,
greg k-h
> 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.
>
> > > > 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.
>
> See above.
>
> > 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. :-(
Yikes. Stephen, if it is not too much trouble could you move my tree up
just a notch (or a couple) in your awesome build system? I hadn't realized
this dependency (thought it is obvious in hindsight).
Thanks!
P.S.
That won't fix Greg building his own linux-tree by itself, and the option of
using CONFIG_BROKEN should work just fine until 3.4 and which point that can be
reverted.