lkml.org 
[lkml]   [2004]   [Nov]   [26]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    DateSat, 27 Nov 2004 03:03:49 +0100
    FromTomas Carnecky <>
    SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__
    Grzegorz Kulewski wrote:
    > 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.)
    
    Are there really any definitions that belong _only_ to userspace?
    AFAIK all that is in the kernel sources is used by the kernel, so
    there are no headers that would fit into your category 3. There is
    no reason to put such things into the kernel sources.
    
    > 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.
    
    The API can be changed, I don't see any problems with the API
    compatibility, if you document all changes then it's no problem for
    the developers to change their code.
    And the ABI? Well, I compile my kernel by myself, as I do all my 
    userspace (gentoo). And the distributions still could define
    __DEPRECATED__ (or something similar).
    
    I mean.. come on.. how hard is it to change some lines of code,
    some structure names, some function arguments.
    I know that there's a problem if you have binary only files, but
    I doubt that anyone is running a exe that was compiled for against
    kernel 2.0 and every big company compiles their projects against each
    stable kernel line.
    Oh.. and I forgot, you usually don't include the kernel headers in your
    'hello world' program, most of the applications use (g)libc, one big
    library, so you'd need to change only very few projects, although I
    admit that can be rather big projects, but still...
    
    BTW, how much smaller would the kernel be if we removed all the
    backwards compatibility? I mean the size of the compiled kernel
    image.
    
    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/
    
    
    \
     
     \ /
      Last update: 2005-03-22 14:08    [from the cache]
    ©2003-2008