From: Michael Ellerman <mpe@ellerman.id.au> Date: 2014-10-23 05:07:24
kcmp.h appears to be part of the API, it's documented in kcmp(2), and
the selftests/kcmp code uses it. So move it to uapi so it's actually
exported.
Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
---
include/linux/kcmp.h | 13 +------------
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/kcmp.h | 17 +++++++++++++++++
3 files changed, 19 insertions(+), 12 deletions(-)
create mode 100644 include/uapi/linux/kcmp.h
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2014-10-23 05:07:31
Don't prevent the test building on non-x86. Just try and build it and
let the chips fall where they may.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/kcmp/Makefile | 14 --------------
1 file changed, 14 deletions(-)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2014-10-23 05:07:50
The kcmp test mucks with the include path to bring in the kernel
headers, and x86 headers too for reasons that are not clear.
Now that kcmp.h is exported none of that should be necessary.
Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
---
tools/testing/selftests/kcmp/Makefile | 4 ----
1 file changed, 4 deletions(-)
On Thu, Oct 23, 2014 at 04:07:12PM +1100, Michael Ellerman wrote:
kcmp.h appears to be part of the API, it's documented in kcmp(2), and
the selftests/kcmp code uses it. So move it to uapi so it's actually
exported.
Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
On Thu, Oct 23, 2014 at 04:07:13PM +1100, Michael Ellerman wrote:
The kcmp test mucks with the include path to bring in the kernel
headers, and x86 headers too for reasons that are not clear.
Now that kcmp.h is exported none of that should be necessary.
Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
The reason was to be able to run test without userspace headers generated.
Still this one is better I think.
Acked-by: Cyrill Gorcunov <redacted>
On Thu, Oct 23, 2014 at 04:07:14PM +1100, Michael Ellerman wrote:
Don't prevent the test building on non-x86. Just try and build it and
let the chips fall where they may.
Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
kcmp depends on checkpoint/restore config symbol which is known
to work on x86 and (iirc) on arm, that's why x86 was only allowed.
I don't mind to such change but not sure.
If the file is empty except for the uapi include, I think it's better to
delete it completely. The include path logic should ensure we pick the
other one up.
Arnd
If the file is empty except for the uapi include, I think it's better to
delete it completely. The include path logic should ensure we pick the
other one up.
Not that this needs to be addressed in this patch, but this looks broken for
cross compilation. It looks like some of the other selftests use:
CC = $(CROSS_COMPILE)gcc
But perhaps this should be set (and perhaps with ':=') once at the top level.
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Not that this needs to be addressed in this patch, but this looks broken for
cross compilation. It looks like some of the other selftests use:
CC = $(CROSS_COMPILE)gcc
It makes sense to fix the cross-compile problem now, since
this patch is extending the support to other archs.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
If the file is empty except for the uapi include, I think it's better to
delete it completely. The include path logic should ensure we pick the
other one up.
Good point, somehow managed to miss this.
Michael,
Are you planning to send v2 to address the comments?
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
Not that this needs to be addressed in this patch, but this looks broken for
cross compilation. It looks like some of the other selftests use:
CC = $(CROSS_COMPILE)gcc
It makes sense to fix the cross-compile problem now, since
this patch is extending the support to other archs.
thanks,
-- Shuah
Please address the cross-compile problems in your next patch version.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
On Thu, 2014-10-23 at 16:07 +1100, Michael Ellerman wrote:
quoted
kcmp.h appears to be part of the API, it's documented in kcmp(2), and
the selftests/kcmp code uses it. So move it to uapi so it's actually
exported.
Looks like this series fell through the cracks?
It still applies on rc6. Should I resend?
cheers
quoted
Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
I am expecting a patch v2 for the series based on the comments
on the series. Please see my responses to the individual patch
threads.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
Not that this needs to be addressed in this patch, but this looks broken for
cross compilation. It looks like some of the other selftests use:
CC = $(CROSS_COMPILE)gcc
But perhaps this should be set (and perhaps with ':=') once at the top level.
The best solution IMHO is:
CC := $(CROSS_COMPILE)$(CC)
Because it allows cross compiling, but also allows overriding of CC.
Will resend with that change.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2014-12-02 05:53:57
On Thu, 2014-10-23 at 10:09 +0400, Cyrill Gorcunov wrote:
On Thu, Oct 23, 2014 at 04:07:14PM +1100, Michael Ellerman wrote:
quoted
Don't prevent the test building on non-x86. Just try and build it and
let the chips fall where they may.
Signed-off-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
kcmp depends on checkpoint/restore config symbol which is known
to work on x86 and (iirc) on arm, that's why x86 was only allowed.
I don't mind to such change but not sure.
Yeah I understand. It's helpful for the other architectures to be able to build
the test, that way we at least know that it's something we should think about
implementing/fixing. If the test doesn't build at all then we just ignore it :)
cheers