Message-ID: <41A7D814.6060900@dbservice.com>
Date: Sat, 27 Nov 2004 02:27:48 +0100
From: Tomas Carnecky <tom@dbservice.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Grzegorz Kulewski <kangur@polcom.net>
Cc: David Howells <dhowells@redhat.com>, torvalds@osdl.org, hch@infradead.org,
       matthew@wil.cx, dwmw2@infradead.org, aoliva@redhat.com,
       linux-kernel@vger.kernel.org, libc-hacker@sources.redhat.com
Subject: Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
References: <19865.1101395592@redhat.com> <Pine.LNX.4.60.0411270049520.29718@alpha.polcom.net>
In-Reply-To: <Pine.LNX.4.60.0411270049520.29718@alpha.polcom.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1698
Lines: 37

Grzegorz Kulewski wrote:
> On Thu, 25 Nov 2004, David Howells wrote:
> 
>>     (b) Make kernel file #include the user file.
> 
> 
> Does kernel really need to include user headers? When it is definition
 > of some const then it should be defined in one file (to be sure it has
 > only one definition).

You have do define a interface between the kernel and the userspace..
you either include kernel headers from userspace (with a lot of 
__KERNEL__ in them) or you make separate headers with the definitions 
and include them in both kernel and userspace (better).
BTW, these are not userspace headers like the ones in /usr/include, 
those are just special headers preparated so that they can be included 
both from the kernel and userspace.

> But user headers may have some compatibility hacks
> that kernel do not need (and even maybe does not want) to have.

About the compatibility hacks.. now it's time to remove them, together 
with this change. I don't think this will happen before 2.7/2.8 and 
until then all should have changed their code.
If you announce these changes soon enough and the developers have enough 
time to change their code, I don't see any problems.
Maybe you also could wrap these definitions in some #ifdef's and mark 
them as deprecated and write somewhere that they'll be removed in the 
next stable tree (2.8). So you could check if a library compiles with 
the new headers or if it still uses some old definitions.

tom
-
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/