OK... I have had a thought grinding in my head for a while, and wanted
to throw it out for everyone to think about...
In the libc4/libc5 days, we attempted to use kernel headers in user
space. This was a total mess, not the least because the kernel
headers tended to pull in a lot of other kernel headers, and the
datatypes were unsuitable to have spead all across userspace.
In glibc, the official rule is "don't use kernel headers." This
causes problems, because certain aspects of the kernel ABI is only
available through the include files, and reproducing them by hand is
tedious and error-prone.
I'm in the process of writing a very tiny libc for initramfs, and will
likely have to deal with how to use the kernel ABI as well.
It seems to me that a reasonable solution for how to do this is not
for user space to use kernel headers, but for user space and the
kernel to share a set of common ABI description files[1]. These files
should be highly stylized, and only describe things visible to user
space. Furthermore, if they introduce types, they should use the
already-established __kernel_ namespace, and of course __s* and __u*
could be used for specific types.
This means that we would be able to get rid of #if(n)def __KERNEL__ in
the main kernel header files, because there would be a separation by
file location -- something in the main kernel include files could
include the ABI description files, but the opposite should never be
true.
I would like to propose that these files be set up in the #include
namespace as <linux/abi/*>, with <linux/abi/arch/*> for any
architecture-specific support files (I do believe, however, that those
files should only be included by files in the linux/abi/ root. This
probably would be a symlink to ../asm/abi in the kernel sources,
unless we change the kernel include layout.) The linux/ namespace is
universally reserved for the kernel, and unlike <abi/*> I don't know
of any potential conflicts. I was considered <kabi/*>, but it seems
cleaner to use existing namespace.
If people think this is an idea, I will try to set up the
infrastructure as part of my work on klibc, although I'm definitely
not going to be able to migrate every portion of every include file
that needs to be migrated all by myself.
Thoughts?
-hpa
[1] I'm assuming here they are C include files, just because it's a
common language to everyone; however, it would be possible to create
an "ABI description language" which would compile to C headers as well
as perhaps other formats (assembly language support files?), ...)
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:18 EST