public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mariusz Mazur <mmazur@kernel.pl>
To: linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] linux-libc-headers 2.6.3.0
Date: Wed, 3 Mar 2004 19:08:41 +0100	[thread overview]
Message-ID: <200403031829.41394.mmazur@kernel.pl> (raw)
In-Reply-To: <m37jy4cuaw.fsf@defiant.pm.waw.pl>

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

  parent reply	other threads:[~2004-03-03 18:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-29 18:42 [ANNOUNCE] linux-libc-headers 2.6.3.0 Mariusz Mazur
2004-02-29 20:19 ` H. Peter Anvin
2004-02-29 20:30   ` Mariusz Mazur
2004-02-29 21:03     ` H. Peter Anvin
2004-02-29 21:21       ` Mariusz Mazur
2004-02-29 21:33         ` Måns Rullgård
2004-03-01 14:42           ` Chris Friesen
2004-03-01 18:10             ` Krzysztof Halasa
2004-03-03 12:49               ` Måns Rullgård
2004-03-03 15:22               ` Sam Ravnborg
2004-03-03 16:49                 ` Krzysztof Halasa
2004-03-04 16:50                   ` Jeff Garzik
2004-03-04 18:49                     ` [Linuxabi] " H. Peter Anvin
2004-03-04  4:43                 ` [Linuxabi] " H. Peter Anvin
2004-03-03 18:08               ` Mariusz Mazur [this message]
2004-03-03 19:20                 ` [ANNOUNCE] " Grzegorz Kulewski
2004-03-04 14:13                 ` Krzysztof Halasa
2004-03-04 20:49                   ` Mariusz Mazur
2004-03-04 21:27                     ` Chris Friesen
2004-03-04 22:52                       ` Mariusz Mazur
2004-03-04 23:32                         ` Chris Friesen
2004-03-05 17:02                     ` Krzysztof Halasa
2004-03-05 23:44                       ` Grzegorz Kulewski
2004-03-06 22:30                         ` Krzysztof Halasa
2004-03-07  1:15                           ` Paul Jackson
2004-03-07 19:00                             ` Krzysztof Halasa
2004-03-08  1:28                               ` Paul Jackson
2004-03-08 15:03                                 ` Krzysztof Halasa
2004-03-08 15:37                                   ` Chris Friesen
2004-03-08 20:27                                     ` Krzysztof Halasa
2004-02-29 21:25     ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200403031829.41394.mmazur@kernel.pl \
    --to=mmazur@kernel.pl \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox