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
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Subject: Re: [ANNOUNCE] linux-libc-headers 2.6.3.0
Date: Thu, 4 Mar 2004 21:49:36 +0100	[thread overview]
Message-ID: <200403042149.36604.mmazur@kernel.pl> (raw)
In-Reply-To: <m3brnc8zun.fsf@defiant.pm.waw.pl>

On Thursday 04 of March 2004 15:13, Krzysztof Halasa wrote:
> Is it the kernel which is based on glibc, or is it glibc (and the rest of
> the userland as glibc isn't that special) using the kernel interface?
>
> The kernel doesn't need glibc at all, I don't know why do you want it
> to require some external headers to compile.
> Should the kernel behave differently when compiled with different glibc
> header sets? :-)

I never said kernel should require glibc - it shouldn't (mind you I don't do 
kernelland headers). But kernel does duplicate each and every structure 
provided by glibc. It has to. The Bad Thing (tm) is that all (well... allmost 
all - lots of linux headers don't parse correctly in userspace) of those 
structures get exported to userland. And programmers use them. They don't 
include <sys/resource.h>, but <linux/resource.h>. And that causes conflicts 
(and is bad practice).

> IMHO all the defines should be in the kernel tree. Glibc can and should
> use them, as it uses the ABI.

Parts of abi that are standardized 
(http://www.opengroup.org/onlinepubs/007904975/ - this thing; check the 
headers section), should be imho provided by C libs. These things do not 
change (they can't or everything would blow up) and I see no reason why glibc 
should rely on having additional headers available, just to do what it's 
supposed to.

> The open question (of much less importance) is if we want to keep
> the existing include/ layout or to move public parts to include/linux-abi
> etc. It still has to reside in the kernel tree, though. I'd go with the
> former for now as it requires less work. OTOH the latter might be
> cleaner.

Userland headers should be kept in /usr/include/{asm,linux}. I see no reason 
to change that (kernel headers have no business being in /usr/include btw). 
As to linux-common linux-kernelonly and linux-userland headers (linux-common 
used by both) - I just find it weird for userland to require kernel sources. 
Linux is supposed to have stable abi.

> > And we have to remember 2.4 compatibilities (which linux-libc-headers
> > have) -
> > is 2.6 kernel a place for them?
>
> Examples?
> If they are part of kernel API/ABI, then of course they are still used
> by 2.6 kernel and they need to be there. If they aren't used by the
> kernel (old #define names for instance) they should go to glibc headers
> (#ifndef xxx #define xxx etc.).

Additionall defines mostly. Probably some extra structures.


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

  reply	other threads:[~2004-03-04 20:53 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               ` [ANNOUNCE] " Mariusz Mazur
2004-03-03 19:20                 ` Grzegorz Kulewski
2004-03-04 14:13                 ` Krzysztof Halasa
2004-03-04 20:49                   ` Mariusz Mazur [this message]
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=200403042149.36604.mmazur@kernel.pl \
    --to=mmazur@kernel.pl \
    --cc=khc@pm.waw.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