Re: [RFC] Splitting out kernel<=>userspace ABI headers

[hpa@zytor.com (H. Peter Anvin)]

Followup to:  <20050902214231.GA10230@ccure.user-mode-linux.org>
By author:    Jeff Dike <jdike@addtoit.com>
In newsgroup: linux.dev.kernel
> 
> UML really needs something like this, both 1 and 2.  See
> 	http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/34d3c02372861a5c/71816a3c7863ea2b?lnk=st&q=%22jeff+dike%22&rnum=27&hl=en#71816a3c7863ea2b
> for my take on system.h and ptrace.h when a change in the host
> architecture broke the UML build.
> 
> UML takes most of its headers from the underlying arch.  It simplifies
> things since most of the definitions are usable in UML.  I don't have
> to clone and maintain my versions of all the other arch headers.
> 
> OTOH, there are things in those headers which UML can't use, and these
> are eliminated in various ways (undefining them after the include of
> the host arch header, redefining them before the include).  But this
> is a pain.
> 
> It has long been my opinion that splitting headers into userspace
> usable and userspace unusable pieces is the right thing for UML.  Less
> clear for the host arch.
> 
> Your post seems to indicate that there is a non-UML demand for exactly
> this.
> 

There definitely is.  The kernel needs to export its ABI in a way that
userspace (UML, various libcs, etc) can import in a sane manner.  In
addition, the Linux kernel contains a fair bit of
architecture-specific support which go well beyond what one can
typically find in userspace, and it would be nice to have those.

The current linux-libc-headers aren't it, because they have a fair bit
of glibc-centric assumptions in those headers.  That's part of why
klibc doesn't use them.

We should probably also consider the licensing of headers that are
meant to be included into userspace.  Userspace still includes a fair
bit of GPL headers, which is technically not kosher.

	-hpa