From: miquels@cistron.nl (Miquel van Smoorenburg)
To: linux-kernel@vger.rutgers.edu
Subject: Re: RLIM_INFINITY inconsistency between archs
Date: 1 Aug 2000 09:36:57 GMT [thread overview]
Message-ID: <8m65np$mm3$1@enterprise.cistron.net> (raw)
In-Reply-To: 8m54u3$dh0$1@cesium.transmeta.com
In article >8m54u3$dh0$1@cesium.transmeta.com>,
H. Peter Anvin <hpa@zytor.com> wrote:
>Followup to: <8m4uri$d9e$1@enterprise.cistron.net>
>By author: miquels@cistron.nl (Miquel van Smoorenburg)
>In newsgroup: linux.dev.kernel
>>
>> >> Everything in /usr/include belongs to and depends on glibc, not
>> >> the currently running kernel.
>> >
>> >Unfortunately that doesn't work very well. For user-space daemons
>> >which talk to Linux-specific kernel interfaces, such as automount, you
>> >need both the glibc and the Linux kernel headers.
>>
>> Yes, but you can't mix&match anyway. For stuff like that you're
>> probably best off by using a talktokernel.c file that is
>> compiled with -I/path/to/kernel/include while the rest of the
>> daemon doesn't know about kernel internals.
>>
>> That could and perhaps should be fixed, but I think that is
>> a different issue entirely.
>
>For most kernel interface daemons, that is not an option. You need to
>be able to translate (or just transfer information) between
>glibc-provided and kernel-provided data structures, so you need to be
>able to include all the datatypes.
Why? As I said you can use a glue layer. Note that you still
cannot mix /usr/include/net and /usr/src/linux/include/net anyway,
so clashes will always exist with the current system.
I agree it should probably be fixed.
>Let's get this straight: #include <linux/*> and #include <asm/*> are
>*expected* to be the kernel headers. This is a completely different
>issue from the fact that glibc headers shouldn't #include these
>headers like libc5 did.
But again as I said that is a different issue. This thread (with the
misleading Subject: header) is mostly about how to build modules
correctly.
There are 3 different issues here:
1. Consistent build environment for 3rd party modules
2. kernel-provided data structures for system daemons like autofs
3. kernel-provided data structures being used in glibc headers
I was merely talking about #1
Mike.
--
Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-08-01 9:17 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200007271459.KAA04701@tsx-prime.MIT.EDU>
[not found] ` <200007271531.KAA89926@tomcat.admin.navo.hpc.mil>
2000-07-31 14:57 ` RLIM_INFINITY inconsistency between archs Kai Henningsen
2000-07-31 17:35 ` Richard B. Johnson
2000-07-31 20:06 ` Mike Galbraith
2000-07-31 21:15 ` Miquel van Smoorenburg
2000-07-31 21:49 ` Richard B. Johnson
2000-07-31 22:39 ` Miquel van Smoorenburg
2000-07-31 22:13 ` H. Peter Anvin
2000-07-31 22:33 ` Miquel van Smoorenburg
2000-08-01 0:17 ` H. Peter Anvin
2000-08-01 0:43 ` wingel
2000-08-01 1:00 ` H. Peter Anvin
2000-08-01 2:06 ` wingel
2000-08-01 9:36 ` Miquel van Smoorenburg [this message]
2000-08-01 17:03 ` H. Peter Anvin
2000-08-01 21:50 ` Miquel van Smoorenburg
2000-08-01 2:18 ` Mike Castle
2000-08-01 2:30 ` wingel
2000-08-01 23:55 ` Mike Castle
2000-08-02 0:18 ` H. Peter Anvin
2000-08-02 9:28 ` Miquel van Smoorenburg
2000-08-04 1:07 ` H. Peter Anvin
2000-08-01 17:03 ` H. Peter Anvin
2000-08-01 2:11 ` Mike Castle
2000-08-01 9:38 ` Miquel van Smoorenburg
2000-08-01 23:44 ` Mike Castle
2000-08-02 18:16 ` peter swain
2000-07-31 17:31 Jesse Pollard
[not found] <20000728112353Z160228-16385+645@vger.rutgers.edu>
2000-07-31 15:26 ` Kai Henningsen
2000-08-01 7:53 ` David Howells
2000-08-01 18:15 ` Kai Henningsen
2000-08-02 6:52 ` wingel
[not found] <FyFI8n.IpM@spuddy.mew.co.uk>
2000-07-29 10:34 ` Stephen Harris
[not found] <200007281315.OAA30398@flint.arm.linux.org.uk>
2000-07-29 1:09 ` David Howells
[not found] <200007272122.RAA04791@tsx-prime.MIT.EDU>
[not found] ` <m2hf9bnm95.fsf@euler.axel.nom>
[not found] ` <20000728162225.A4317@saw.sw.com.sg>
2000-07-29 0:51 ` Mike Castle
[not found] <no.id>
2000-07-28 22:10 ` Adam Sampson
2000-07-28 22:20 ` Adam Sampson
2000-07-29 13:23 ` Miquel van Smoorenburg
[not found] <3981ED0C.CBE0A0F9@transmeta.com>
2000-07-28 21:02 ` Khimenko Victor
[not found] <Pine.LNX.4.21.0007280808460.73-100000@rc.priv.hereintown.net>
2000-07-28 20:56 ` Stuart Lynne
2000-07-28 20:13 ` clubneon
[not found] <E13HsBT-00033e-00@the-village.bc.nu>
[not found] ` <200007281405.JAA101655@tomcat.admin.navo.hpc.mil>
2000-07-28 14:11 ` Jamie Lokier
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='8m65np$mm3$1@enterprise.cistron.net' \
--to=miquels@cistron.nl \
--cc=linux-kernel@vger.rutgers.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.