Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or directory
Caused by commits ba351b02ab11 ("staging: ramster: local compression +
tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
I have used the version of the staging tree from next-20120209 for today.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Fri, Feb 10, 2012 at 03:58:00PM +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/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
> drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
> drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
> drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
> drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or directory
>
> Caused by commits ba351b02ab11 ("staging: ramster: local compression +
> tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
>
> I have used the version of the staging tree from next-20120209 for today.
Ugh, I wonder why it builds here, very odd.
Dan, care to send me a patch to fix this?
greg k-h
> From: Greg KH [mailto:[email protected]]
> Subject: Re: linux-next: build failure after merge of the staging tree
>
> On Fri, Feb 10, 2012 at 03:58:00PM +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/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
> > drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function
> 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
> > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
> > drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function
> 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
> > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or
> directory
> >
> > Caused by commits ba351b02ab11 ("staging: ramster: local compression +
> > tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
> >
> > I have used the version of the staging tree from next-20120209 for today.
>
> Ugh, I wonder why it builds here, very odd.
>
> Dan, care to send me a patch to fix this?
> > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such
Hmmm... it appears that Seth's zsmalloc patch for drivers/staging/zcache
removed xvmalloc.[ch] from drivers/staging/zram while drivers/staging/ramster
is still depending on it. :-( I hadn't planned for both ramster
and zsmalloc-replacing-xvmalloc to be merged at the same time... I guess
this is exactly the kind of problem linux-next is designed to wring out!
Greg, FOR NOW, PLEASE JUST REVERT the ramster patchset from staging-next.
I am working on a v5 anyway and will roll in a copy of the xvmalloc.[ch]
code into it for now and, since Seth's patch should be in linux-next
by the time I am done (hopefully next week), I can test build ramster v5
with linux-next to ensure all the above problems are resolved before
resubmitting.
(Seth, I could also switch ramster v5 to depend on zsmalloc instead of
xvmalloc, but since I've done all my ramster testing on xvmalloc,
I think I would prefer to make that transition later.)
Sorry, Stephen and Greg, for the hassle!
Dan
On Fri, Feb 10, 2012 at 09:21:46AM -0800, Dan Magenheimer wrote:
> > From: Greg KH [mailto:[email protected]]
> > Subject: Re: linux-next: build failure after merge of the staging tree
> >
> > On Fri, Feb 10, 2012 at 03:58:00PM +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/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
> > > drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function
> > 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
> > > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
> > > drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function
> > 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
> > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or
> > directory
> > >
> > > Caused by commits ba351b02ab11 ("staging: ramster: local compression +
> > > tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
> > >
> > > I have used the version of the staging tree from next-20120209 for today.
> >
> > Ugh, I wonder why it builds here, very odd.
> >
> > Dan, care to send me a patch to fix this?
>
> > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such
>
> Hmmm... it appears that Seth's zsmalloc patch for drivers/staging/zcache
> removed xvmalloc.[ch] from drivers/staging/zram while drivers/staging/ramster
> is still depending on it. :-( I hadn't planned for both ramster
> and zsmalloc-replacing-xvmalloc to be merged at the same time... I guess
> this is exactly the kind of problem linux-next is designed to wring out!
>
> Greg, FOR NOW, PLEASE JUST REVERT the ramster patchset from staging-next.
> I am working on a v5 anyway and will roll in a copy of the xvmalloc.[ch]
> code into it for now and, since Seth's patch should be in linux-next
> by the time I am done (hopefully next week), I can test build ramster v5
> with linux-next to ensure all the above problems are resolved before
> resubmitting.
>
> (Seth, I could also switch ramster v5 to depend on zsmalloc instead of
> xvmalloc, but since I've done all my ramster testing on xvmalloc,
> I think I would prefer to make that transition later.)
>
> Sorry, Stephen and Greg, for the hassle!
Ok, now reverted, what a mess...
greg k-h
On 02/10/2012 11:43 AM, Greg KH wrote:
> On Fri, Feb 10, 2012 at 09:21:46AM -0800, Dan Magenheimer wrote:
>>> From: Greg KH [mailto:[email protected]]
>>> Subject: Re: linux-next: build failure after merge of the staging tree
>>>
>>> On Fri, Feb 10, 2012 at 03:58:00PM +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/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
>>>> drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function
>>> 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
>>>> drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
>>>> drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function
>>> 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
>>>> drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or
>>> directory
>>>>
>>>> Caused by commits ba351b02ab11 ("staging: ramster: local compression +
>>>> tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
>>>>
>>>> I have used the version of the staging tree from next-20120209 for today.
>>>
>>> Ugh, I wonder why it builds here, very odd.
>>>
>>> Dan, care to send me a patch to fix this?
>>
>>>> drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such
>>
>> Hmmm... it appears that Seth's zsmalloc patch for drivers/staging/zcache
>> removed xvmalloc.[ch] from drivers/staging/zram while drivers/staging/ramster
>> is still depending on it. :-( I hadn't planned for both ramster
>> and zsmalloc-replacing-xvmalloc to be merged at the same time... I guess
>> this is exactly the kind of problem linux-next is designed to wring out!
>>
>> Greg, FOR NOW, PLEASE JUST REVERT the ramster patchset from staging-next.
>> I am working on a v5 anyway and will roll in a copy of the xvmalloc.[ch]
>> code into it for now and, since Seth's patch should be in linux-next
>> by the time I am done (hopefully next week), I can test build ramster v5
>> with linux-next to ensure all the above problems are resolved before
>> resubmitting.
>>
>> (Seth, I could also switch ramster v5 to depend on zsmalloc instead of
>> xvmalloc, but since I've done all my ramster testing on xvmalloc,
>> I think I would prefer to make that transition later.)
>>
>> Sorry, Stephen and Greg, for the hassle!
>
> Ok, now reverted, what a mess...
Sounds like the ramster has been reverted already, but the removal
of xvmalloc was done in its own commit (from staging-next):
b154ff05e1b0d749231a71896c90e38657f8e675 staging: zram: remove xvmalloc
If you revert just this commit, that should restore the xvmalloc files.
Of course this doesn't resolve the "implicit declaration of function"
errors.
--
Seth
> From: Greg KH [mailto:[email protected]]
> Subject: Re: linux-next: build failure after merge of the staging tree
>
> On Fri, Feb 10, 2012 at 09:21:46AM -0800, Dan Magenheimer wrote:
> > > From: Greg KH [mailto:[email protected]]
> > > Subject: Re: linux-next: build failure after merge of the staging tree
> > >
> > > On Fri, Feb 10, 2012 at 03:58:00PM +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/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
> > > > drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function
> > > 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
> > > > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
> > > > drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function
> > > 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
> > > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or
> > > directory
> > > >
> > > > Caused by commits ba351b02ab11 ("staging: ramster: local compression +
> > > > tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
> > > >
> > > > I have used the version of the staging tree from next-20120209 for today.
> > >
> > > Ugh, I wonder why it builds here, very odd.
> > >
> > > Dan, care to send me a patch to fix this?
> >
> > > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such
> >
> > Hmmm... it appears that Seth's zsmalloc patch for drivers/staging/zcache
> > removed xvmalloc.[ch] from drivers/staging/zram while drivers/staging/ramster
> > is still depending on it. :-( I hadn't planned for both ramster
> > and zsmalloc-replacing-xvmalloc to be merged at the same time... I guess
> > this is exactly the kind of problem linux-next is designed to wring out!
> >
> > Greg, FOR NOW, PLEASE JUST REVERT the ramster patchset from staging-next.
> > I am working on a v5 anyway and will roll in a copy of the xvmalloc.[ch]
> > code into it for now and, since Seth's patch should be in linux-next
> > by the time I am done (hopefully next week), I can test build ramster v5
> > with linux-next to ensure all the above problems are resolved before
> > resubmitting.
> >
> > (Seth, I could also switch ramster v5 to depend on zsmalloc instead of
> > xvmalloc, but since I've done all my ramster testing on xvmalloc,
> > I think I would prefer to make that transition later.)
> >
> > Sorry, Stephen and Greg, for the hassle!
>
> Ok, now reverted, what a mess...
>
> greg k-h
OK, I have just posted the ramster v5 patchset which applies against
linux-3.2. I've test-built it against linux-next... it only gets
the normal minor merge conflicts for adding a line to
drivers/staging/Makefile and Kconfig.
Sorry again for the inconvenience. At least V5 has some nice
improvements over V4, see: https://lkml.org/lkml/2012/2/14/396
Thanks,
Dan
On Tue, Feb 14, 2012 at 03:43:31PM -0800, Dan Magenheimer wrote:
> > From: Greg KH [mailto:[email protected]]
> > Subject: Re: linux-next: build failure after merge of the staging tree
> >
> > On Fri, Feb 10, 2012 at 09:21:46AM -0800, Dan Magenheimer wrote:
> > > > From: Greg KH [mailto:[email protected]]
> > > > Subject: Re: linux-next: build failure after merge of the staging tree
> > > >
> > > > On Fri, Feb 10, 2012 at 03:58:00PM +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/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
> > > > > drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function
> > > > 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
> > > > > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
> > > > > drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function
> > > > 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
> > > > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or
> > > > directory
> > > > >
> > > > > Caused by commits ba351b02ab11 ("staging: ramster: local compression +
> > > > > tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
> > > > >
> > > > > I have used the version of the staging tree from next-20120209 for today.
> > > >
> > > > Ugh, I wonder why it builds here, very odd.
> > > >
> > > > Dan, care to send me a patch to fix this?
> > >
> > > > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such
> > >
> > > Hmmm... it appears that Seth's zsmalloc patch for drivers/staging/zcache
> > > removed xvmalloc.[ch] from drivers/staging/zram while drivers/staging/ramster
> > > is still depending on it. :-( I hadn't planned for both ramster
> > > and zsmalloc-replacing-xvmalloc to be merged at the same time... I guess
> > > this is exactly the kind of problem linux-next is designed to wring out!
> > >
> > > Greg, FOR NOW, PLEASE JUST REVERT the ramster patchset from staging-next.
> > > I am working on a v5 anyway and will roll in a copy of the xvmalloc.[ch]
> > > code into it for now and, since Seth's patch should be in linux-next
> > > by the time I am done (hopefully next week), I can test build ramster v5
> > > with linux-next to ensure all the above problems are resolved before
> > > resubmitting.
> > >
> > > (Seth, I could also switch ramster v5 to depend on zsmalloc instead of
> > > xvmalloc, but since I've done all my ramster testing on xvmalloc,
> > > I think I would prefer to make that transition later.)
> > >
> > > Sorry, Stephen and Greg, for the hassle!
> >
> > Ok, now reverted, what a mess...
> >
> > greg k-h
>
> OK, I have just posted the ramster v5 patchset which applies against
> linux-3.2. I've test-built it against linux-next... it only gets
> the normal minor merge conflicts for adding a line to
> drivers/staging/Makefile and Kconfig.
Please resend after fixing that conflict, as it would require me to edit
it by hand in order to apply this. As you have already redone the
patch, there's no reason I should have to do this, right?
thanks,
greg k-h
> From: Greg KH [mailto:[email protected]]
> Subject: Re: linux-next: build failure after merge of the staging tree
>
> > > Ok, now reverted, what a mess...
> > >
> > > greg k-h
> >
> > OK, I have just posted the ramster v5 patchset which applies against
> > linux-3.2. I've test-built it against linux-next... it only gets
> > the normal minor merge conflicts for adding a line to
> > drivers/staging/Makefile and Kconfig.
>
> Please resend after fixing that conflict, as it would require me to edit
> it by hand in order to apply this. As you have already redone the
> patch, there's no reason I should have to do this, right?
OK. I'm not quite sure how to generate a patchset or a
git commit-set that applies cleanly against two different
trees (3.2 and linux-next), but I guess common sense should
tell me that, since the patches have to go through staging-next
first and you are applying patches rather than git-pull'ing,
staging-next should be my preferred choice for a base.
Do you want me to resend all 6 patches? The only patch
affected is patch 6 of 6. All others apply cleanly.
Let me know and I will resend one or all tomorrow.
Sorry for the noise/hassle, but this is a learning process...
Dan
On Tue, Feb 14, 2012 at 04:54:37PM -0800, Dan Magenheimer wrote:
> > From: Greg KH [mailto:[email protected]]
> > Subject: Re: linux-next: build failure after merge of the staging tree
> >
> > > > Ok, now reverted, what a mess...
> > > >
> > > > greg k-h
> > >
> > > OK, I have just posted the ramster v5 patchset which applies against
> > > linux-3.2. I've test-built it against linux-next... it only gets
> > > the normal minor merge conflicts for adding a line to
> > > drivers/staging/Makefile and Kconfig.
> >
> > Please resend after fixing that conflict, as it would require me to edit
> > it by hand in order to apply this. As you have already redone the
> > patch, there's no reason I should have to do this, right?
>
> OK. I'm not quite sure how to generate a patchset or a
> git commit-set that applies cleanly against two different
> trees (3.2 and linux-next), but I guess common sense should
> tell me that, since the patches have to go through staging-next
> first and you are applying patches rather than git-pull'ing,
> staging-next should be my preferred choice for a base.
Exactly, how could I apply them to two trees? For that case, how can I
go back in time and apply them to 3.2?
> Do you want me to resend all 6 patches? The only patch
> affected is patch 6 of 6. All others apply cleanly.
> Let me know and I will resend one or all tomorrow.
All would be best, also please thread them properly, 'git send-email'
will do this for you, please use it.
greg k-h
> From: Greg KH [mailto:[email protected]]
>
> On Tue, Feb 14, 2012 at 04:54:37PM -0800, Dan Magenheimer wrote:
> > > From: Greg KH [mailto:[email protected]]
> > > Subject: Re: linux-next: build failure after merge of the staging tree
> > >
> > > > OK, I have just posted the ramster v5 patchset which applies against
> > > > linux-3.2. I've test-built it against linux-next... it only gets
> > > > the normal minor merge conflicts for adding a line to
> > > > drivers/staging/Makefile and Kconfig.
> > >
> > > Please resend after fixing that conflict, as it would require me to edit
> > > it by hand in order to apply this. As you have already redone the
> > > patch, there's no reason I should have to do this, right?
> >
> > Do you want me to resend all 6 patches? The only patch
> > affected is patch 6 of 6. All others apply cleanly.
> > Let me know and I will resend one or all tomorrow.
>
> All would be best, also please thread them properly, 'git send-email'
> will do this for you, please use it.
OK, posted (*). BTW, I _was_ using git send-email, just didn't know
that "git send-email patch0 patch1 patch2 ..." would cause them
to be threaded. (I was using git send-email patch0;
git send-email patch1; git send-email patch2...)
Thanks again for your patience and help! I think RAMster
can now be successfully queued with no linux-next merge issues!
Dan
* http://driverdev.linuxdriverproject.org/pipermail/devel/2012-February/024614.html