lkml.org 
[lkml]   [2004]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__
On Sat, 27 Nov 2004, Tomas Carnecky wrote:

> 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.

Ok, so maybe do it in this way:
1. common headers (included by 2. and 3.)
2. kernel headers (things only for kernel + included 1.)
3. userspace headers (things only for userspace + included 1.)

This way we will have no ifdefs, one definition per thing, user code in
userspace and kernel code in kernelspace only.


>> 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.

Are you talking about breaking userspace (API and ABI) compatibility? And
possibly breaking compatibility with older versions of standards? I do not
think it could happen. (Well at least not for common widely-used APIs).

Instead we can place such userspace only hacks in 3.


Thanks,

Grzegorz Kulewski

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

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.153 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site