User-API header split preliminary patches
Hi Linus,
Can you pull these patches from my GIT repository please?
They prepare the way for splitting out the User API definitions from the standard kernel internal headers into their own header file directories (there will be arch-specific directories as well as the common ones).
They have been in linux-next for roughly three weeks.
I have audited them from my initial patch submission to get rid of patches that are no longer necessary.
I have also built allyesconfig with all the cross-compilers I can create on the full patch spectrum (on the uapi-split branch in the same tree) and eliminated the problems created.
Can you please consider pulling the further patchset that actually performs the split at the end of the merge window. It *will* need regenerating whenever it is pulled, but is mostly scripted.
Thanks,
David
---
The following changes since commit dc47ce90c3a822cd7c9e9339fe4d5f61dcb26b50:
Linux 3.2-rc5 (2011-12-09 15:09:32 -0800)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git for-next
David Howells (17):
UAPI: Fix arch/mips/include/asm/Kbuild to have separate header-y lines
UAPI: Don't include linux/compat.h in sparc's asm/siginfo.h
UAPI: elf_read_implies_exec() is a kernel-only feature - so hide from userspace
UAPI: Make MN10300 use asm-generic/param.h
UAPI: Make M32R use asm-generic/param.h
UAPI: Make FRV use asm-generic/param.h
UAPI: Rearrange definition of HZ in asm-generic/param.h
UAPI: Guard linux/sound.h
UAPI: Guard linux/isdn_divertif.h
UAPI: Guard linux/pmu.h
UAPI: Guard linux/cuda.h
UAPI: Alter the S390 asm include guards to be recognisable by the UAPI splitter
UAPI: Fix nested __KERNEL__ guards in video/edid.h
UAPI: Make linux/patchkey.h easier to parse
UAPI: Fix AHZ multiple inclusion when __KERNEL__ is removed
UAPI: Don't have a #elif clause in a __KERNEL__ guard in linux/soundcard.h
UAPI: Split trivial #if defined(__KERNEL__) && X conditionals
arch/arm/include/asm/hwcap.h | 4 +++- arch/arm/include/asm/swab.h | 7 +++++-- arch/arm/include/asm/unistd.h | 4 +++- arch/frv/include/asm/param.h | 16 +--------------- arch/ia64/include/asm/intrinsics.h | 21 +++++++++++++-------- arch/m32r/include/asm/param.h | 18 +----------------- arch/mips/include/asm/Kbuild | 4 +++- arch/mips/include/asm/types.h | 10 +++++++--- arch/mn10300/include/asm/param.h | 18 +----------------- arch/s390/include/asm/chpid.h | 2 +- arch/s390/include/asm/itcw.h | 2 +- arch/s390/include/asm/mman.h | 4 +++- arch/sparc/include/asm/siginfo.h | 2 -- arch/tile/include/asm/signal.h | 4 +++- include/asm-generic/param.h | 13 +++++++------ include/linux/acct.h | 3 +++ include/linux/cuda.h | 5 +++++ include/linux/elf.h | 18 +++++++++--------- include/linux/isdn_divertif.h | 4 ++++ include/linux/mroute6.h | 4 +++- include/linux/patchkey.h | 4 +++- include/linux/pmu.h | 4 ++++ include/linux/sound.h | 4 ++++ include/linux/soundcard.h | 4 +++- include/video/edid.h | 6 ++---- 25 files changed, 92 insertions(+), 93 deletions(-)
Pulling the rest of the User-API header split patches
Hi Linus,
Thanks for pulling the User-API header split preliminary patches.
Will you be pulling the rest of the patches to actually perform the split at the end of this merge window? If so, as previously mentioned, I'll need to regenerate them before you do.
However, for the moment, I dropped the preliminary patches from my tree and regenerated the rest based on the tree I saw this morning:
http://git.infradead.org/users/dhowells/linux-headers.git/shortlog/refs/heads/uapi-split
I've made 'make allyesconfig' build again on x86_64. arch/x86/lib/insn.c is compiled for use in both userspace and kernelspace, necessitating a bit of #include adjustment, but that was the only necessary change. I've also had Dave Airlie review the preparatory DRM patches and those have been adjusted.
An opinion, if I may: I have been checking the scripts into the GIT tree (with the intention to delete them later) so that a record of them is retained - but I wonder if I should bother... Hopefully, once the scripts are run and the results applied, it won't be necessary to retain the scripts.
Thanks,
David