Re: [ANNOUNCE] linux-libc-headers 2.6.3.0

From: Mariusz Mazur (mmazur_at_kernel.pl)
Date: 03/03/04

  • Next message: Richard B. Johnson: "Re: poll() in 2.6 and beyond" 
    To: linux-kernel@vger.kernel.org
Date:	Wed, 3 Mar 2004 19:08:41 +0100

    On Monday 01 of March 2004 19:10, Krzysztof Halasa wrote:
    > Not sure about it being "official".
    > It may make sense if it's a distribution - many users don't install
    > kernel sources. Still, from a technical point of view, it should be
    > a straight copy of kernel includes - we don't want to maintain two
    > separate sets, do we?

    We do. Abi changes are rather rare so keeping them as a separate tree wouldn't
    add too much work for subsystem maintainers, and it would be a Good Thing
    (tm) to have one place where the whole current abi can be seen. One thing to
    note is that linux headers duplicate many structures and definitions that
    should be (and are) provided by glibc. This causes collisions. My current
    practice is to clear offending linux headers of their content, and simply
    include appropriate libc headers (with a nice warning) from them.
    I can say that about 60-80% of current linux headers do not have proper
    separation of kernel only code (counting in headers that are kernel only, but
    have no visible signs of that fact) and adding that separation would take a
    while. And even if successfull, it would add significant maintainer burden to
    keep the whole thing working (it would probably look like crap too).
    And we have to remember 2.4 compatibilities (which linux-libc-headers have) -
    is 2.6 kernel a place for them?
    (keep in mind I know squat about kernel development, so don't rely on my
    opinions too much)

    My current objective is to remove *all* remaining kernel code from
    linux-libc-headers and add as much 2.4 compatibilities as possible. And this
    will take a loooong time since the majority of headers are kernel only, but
    are not marked as such, or are marked as such on one arch only (ppc guys
    rock :), and assumption that removal of those headers from other archs is
    safe is... well... just an assumption.

    And as to leaving this as a separate project, or trying to push it into the
    kernel - well, I see pros and cons of both options (and it's not my
    decision :). 

    -- 
In the year eighty five ten
God is gonna shake his mighty head
He'll either say,
"I'm pleased where man has been"
Or tear it down, and start again
-
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/
  • Next message: Richard B. Johnson: "Re: poll() in 2.6 and beyond"

    Relevant Pages

    • State of userland headers
      ... When I first created llh, it was a couple of weeks before 2.6.0 came out. ... had a need for those headers, since a new version of PLD distro was supposed ... LLH as it is is not and never will be mergable into mainline kernel. ... llh for the most popular archs and figure out how to build all the various ...
      (Linux-Kernel)
    • Re: State of userland headers
      ... to get changes of this nature into glibc in particular, ... If the headers ... the kernel. ... This would mean that the kabi headers have no ...
      (Linux-Kernel)
    • Re: [PATCH] make headers_install kbuild target.
      ... There are many other users that poke direct in the kernel source also. ... The gentoo people have been collecting patches to clean up the headers: ... For kernel space, you can do it incrementally, since the whole kabi/ ...
      (Linux-Kernel)
    • Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
      ... > just make one thing clear: the kernel headers are for the kernel, ... userland must duplicate the contents of headers in which the kernel ... defines the kerneluserland ABI, tracking changes in them in the ...
      (Linux-Kernel)
    • Re: [RFC] Splitting out kernel<=>userspace ABI headers
      ... >> architecture broke the UML build. ... >> to clone and maintain my versions of all the other arch headers. ... >> usable and userspace unusable pieces is the right thing for UML. ... The kernel needs to export its ABI in a way that ...
      (Linux-Kernel)