Message-Id: <200107151421.f6FELj7H003177@sleipnir.valparaiso.cl>
To: kaih@khms.westfalen.de (Kai Henningsen)
Cc: linux-kernel@vger.kernel.org
Subject: Re: __KERNEL__ removal 
In-Reply-To: Your message of "15 Jul 2001 13:53:00 +0200."
             <84uhW6amw-B@khms.westfalen.de> 
Date: Sun, 15 Jul 2001 10:21:44 -0400
From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
Sender: linux-kernel-owner@vger.kernel.org

kaih@khms.westfalen.de (Kai Henningsen) said:

[...]

> ... but if we are looking for a clean solution to types and constants that  
> are needed to communicate between kernel and user space, IMO the thing to  
> do is to define these in some sort of generic format, and have a tool to  
> generate actual headers from that according to whatever kernel, libc or  
> whoever wants to see. Possibly more than one tool as requirements differ.

Much easier, plain C, no special tools:

   include/linux/...
   include/asm/...
   include/glibc/...

where .../glibc/xyz.h contains the shared parts, and the others feel
free to include that as needed.

The real problem is that the interfaces _do_ change, as new syscalls,
ioctls, and constants show up (so "one set of .h for userland, cast in
stone for all eternity" won't _ever_ do), and that parts of the userland
are tightly bound to the kernel, and _need_ inside knowledge (strace, the
tools for manipulating modules, ...). Plus glibc and userland also
changes...
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616
-
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/