Hi Alexander,
Today's linux-next merge of the kvm-ppc tree got a conflict in
arch/powerpc/include/asm/Kbuild between commit c3617f72036c ("UAPI:
(Scripted) Disintegrate arch/powerpc/include/asm") from the powerpc-merge
tree and commit 4c09029a5639 ("KVM: PPC: Add support for ePAPR idle hcall
in host kernel") from the kvm-ppc tree.
I just removed epapr_hcalls.h from the Kbuild file as I am not sure how
it should be broken up. David, can you have a look at this, please?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
Stephen Rothwell [off-list ref] wrote:
I just removed epapr_hcalls.h from the Kbuild file as I am not sure how
it should be broken up. David, can you have a look at this, please?
Files should be broken up along around __KERNEL__ conditionals. If there are
no __KERNEL__ conditionals, it is assumed that the file is entirely UAPI and
can just be moved.
The problem appears to be this commit:
https://github.com/agraf/linux-2.6/commit/4c09029a5639c955fcf6d65205796e4f1208aed3
From: Liu Yu [off-list ref]
Subject: KVM: PPC: Add support for ePAPR idle hcall in host kernel
Just makes epapr_hcalls.h part of the userspace API in its entirety by this bit
of the patch:
+header-y += epapr_hcalls.h
whilst not adding any __KERNEL__ guards - which is almost certainly incorrect.
At the very least, I would say that the global variable declarations need
limiting to kernel space, and thus so do the inline functions as they emit
inline assembly to jump somewhere specified by one of the global variables
(actually a code array).
So for manual splitting purposes, I would go with just moving all the #defines
prior to the __ASSEMBLY__ guard out to uapi. Everything within the
__ASSEMBLY__ guard is KABI only by the looks of it.
David
On 11.10.2012, at 11:27, David Howells wrote:
Stephen Rothwell [off-list ref] wrote:
=20
quoted
I just removed epapr_hcalls.h from the Kbuild file as I am not sure =
how
quoted
it should be broken up. David, can you have a look at this, please?
=20
Files should be broken up along around __KERNEL__ conditionals. If =
there are
no __KERNEL__ conditionals, it is assumed that the file is entirely =
UAPI and
can just be moved.
=20
The problem appears to be this commit:
=20
=
https://github.com/agraf/linux-2.6/commit/4c09029a5639c955fcf6d65205796e4f=
1208aed3
=20
From: Liu Yu [off-list ref]
Subject: KVM: PPC: Add support for ePAPR idle hcall in host =
kernel
=20
Just makes epapr_hcalls.h part of the userspace API in its entirety by =
this bit
of the patch:
=20
+header-y +=3D epapr_hcalls.h
=20
whilst not adding any __KERNEL__ guards - which is almost certainly =
incorrect.
=20
At the very least, I would say that the global variable declarations =
need
limiting to kernel space, and thus so do the inline functions as they =
emit
inline assembly to jump somewhere specified by one of the global =
variables
(actually a code array).
=20
So for manual splitting purposes, I would go with just moving all the =
#defines
prior to the __ASSEMBLY__ guard out to uapi. Everything within the
__ASSEMBLY__ guard is KABI only by the looks of it.
Do I have to move them to their own header file or can I just #ifdef =
__KERNEL__ around the place where __ASSEMBLY__ starts to the end of the =
file?
Alex
Alexander Graf [off-list ref] wrote:
Do I have to move them to their own header file or can I just #ifdef
__KERNEL__ around the place where __ASSEMBLY__ starts to the end of the
file?
That depends on whether it happens before or after my disintegration script is
run on the header. Ben has pulled my powerpc thing into the powerpc tree
already. If he doesn't mind repulling, then if you give me a patch or a git
branch to fix it, I can apply that and regenerate the powerpc branch.
Otherwise, you need to disintegrate manually:
(1) Move the public part to arch/powerpc/include/uapi/asm/epapr_hcalls.h
(2) #include the public part from arch/powerpc/include/asm/epapr_hcalls.h
(3) Move the "headers-y += epapr_hcalls.h" line from .../asm/Kbuild to
.../uapi/asm/Kbuild.
You should not then need __KERNEL__ guards in either header.
David