# Re: linux-next: manual merge of the kvm-ppc tree with the powerpc-merge tree

- From: Alexander Graf \<hidden\>
- Date: 2012-10-11 13:08:12 
- List: linuxppc-dev
- Page: https://ratatoskr.run/linuxppc-dev/2012/10/3938114
- Thread: https://ratatoskr.run/linux-next/2012/10/3937700/t.md

```text

On 11.10.2012, at 11:27, David Howells wrote:

> Stephen Rothwell [ref] wrote:
>=20
>> 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?
>=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 [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
```