RLIM_INFINITY inconsistency between archs
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
[email protected] (Jesse Pollard) wrote on 27.07.00 in <[email protected]>:
Quoted 6 lines
Might I suggest creating a "
/lib/include" that works something like the/lib/moduleswhere the kernel name is used to generate the directory for the kernel include files?That way the "uname -r" command could be used to set a symbolic link to point to the correct include files at boot time (or install time).
Correct for what?
I think this is silly.
There are two versions of header files people tend to be interested in:
a. The ones corresponding to the libc version their linker will link against. This will be good for 99% of the situations.
b. A special version for some kernel-version-dependant executable. Exact version depends on what they plan to do with that executable - could be most advanced kernel version available, least advanced version available, a specific version whose significance depends on the configuration of a different machine, whatever.
There is no reason to assume that the currently running kernel version is any more relevant than any of the other arguments for b.
Quoted 1 line
This way the kernel that is active would be selecting the correct includes.
Correct for what?
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 11 lines · Kai Henningsen
[email protected] (Jesse Pollard) wrote on 27.07.00 in <[email protected]>:
Quoted 6 lines
Might I suggest creating a "
/lib/include" that works something like the/lib/moduleswhere the kernel name is used to generate the directory for the kernel include files?That way the "uname -r" command could be used to set a symbolic link to point to the correct include files at boot time (or install time).
Correct for what?
I must be able to build kernel modules for a kernel version that I am not yet running. This is not related in any way to what I get from uname -r. Further, I may be building the kernel for an Alpha on an Intel machine, using a cross-compiler.
The de-facto standard has been that /usr/src/linux is a sym-link to the kernel version you wish to build. Why is this expected to be changed?
Since this is a symbolic link, it can cross device boundaries. This makes it very versatile.
/usr/include/linux and /usr/include/asm are symbolic links, referenced
to /usr/src/linux, not a specific version. This makes changing kernel development versions a simple change of a single symbolic link.
Why would anybody change this? I fear that this is another of those; "It doesn't have to be better, only different..." things that have been going around.
Cheers,
Dick Johnson
Penguin: Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 13 lines · Richard B. Johnson
Quoted 11 lines · Kai Henningsen
[email protected] (Jesse Pollard) wrote on 27.07.00 in <[email protected]>:
Quoted 6 lines
Might I suggest creating a "
/lib/include" that works something like the/lib/moduleswhere the kernel name is used to generate the directory for the kernel include files?That way the "uname -r" command could be used to set a symbolic link to point to the correct include files at boot time (or install time).
Correct for what?
<snip>
Quoted 3 lines
Why would anybody change this? I fear that this is another of those; "It doesn't have to be better, only different..." things that have been going around.
Well, I suspect that there is an issue for driver authors/maintainers, but haven't figured out quite what that issue is. Why does it matter?
I really couldn't care less where headers officially live.. as long as it's possiblle [preferably easy] to maintain them where _I_ want them. (and that is nowhere near /)
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
In article >[email protected]>,
Quoted 3 lines · Richard B. Johnson
/usr/include/linuxand/usr/include/asmare symbolic links, referenced to/usr/src/linux, not a specific version. This makes changing kernel development versions a simple change of a single symbolic link.
No. Even Linus himself has been saying for years (and recently even in this thread) that /usr/include/linux and /usr/include/asm should NOT EVER be symlinks to /usr/src/linux
Everything in /usr/include belongs to and depends on glibc, not the currently running kernel.
And if you want to compile modules and use /usr/include/linux for the include files, what are you going to do about networking modules that use include/net ? The one in the kernel source is very, very different from the one in glibc .. so you have to compile with -I/path/to/kernel/include _anyway_
You can't just use /usr/src/linux/include, what if you want to compile against another kernel version? What if you are not root ?
The /lib/modules/version/ stuff is a good idea, but it should contain a `kernel-config' script that outputs the complete CFLAGS that the kernel was compiled with. Easy, simple, enduser friendly.
Mike.
Signature · 6 lines
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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 10 lines · Miquel van Smoorenburg
In article >[email protected]>,
Quoted 3 lines · Richard B. Johnson
/usr/include/linuxand/usr/include/asmare symbolic links, referenced to/usr/src/linux, not a specific version. This makes changing kernel development versions a simple change of a single symbolic link.No. Even Linus himself has been saying for years (and recently even in this thread) that
/usr/include/linuxand/usr/include/asmshould NOT EVER be symlinks to/usr/src/linux
I don't think Linus said that at all. In fact, the first trees that Linus made and distributed were done this way and have become the de-facto standard as a result of this.
Quoted 3 lines
Everything in
/usr/includebelongs to and depends on glibc, not the currently running kernel.
No. I have /usr/include/subdirectories which contain headers for X11, some that contain headers for Motif, some that contain headers for pthreads, bind-4.9.3, etc. These are not glibc headers.
You cannot decide that I can't keep these where they are.
Any portable code is not supposed to include non-portable headers. This means that if your code does:
#include <linux/something.h>
it is not portable. If your portable code is written properly, the presence of links to non-portable headers in /usr/include does nothing. They are never referenced.
When you need to have current kernel headers referenced, your non- portable code (like modules) specifically includes the linux headers. This is now it's been done. I see no reason to change it.
Quoted 9 lines
And if you want to compile modules and use
/usr/include/linuxfor the include files, what are you going to do about networking modules that useinclude/net? The one in the kernel source is very, very different from the one in glibc .. so you have to compile with -I/path/to/kernel/include _anyway_You can't just use
/usr/src/linux/include, what if you want to compile against another kernel version? What if you are not root ?
We don't use /usr/src/linux/include. As stated, the include files are referenced from /usr/include.
Quoted 4 lines
The
/lib/modules/version/stuff is a good idea, but it should contain a `kernel-config' script that outputs the complete CFLAGS that the kernel was compiled with. Easy, simple, enduser friendly.
Cheers,
Dick Johnson
Penguin: Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
In article >[email protected]>,
Quoted 6 lines · Richard B. Johnson
Quoted 3 lines · Miquel van Smoorenburg
No. Even Linus himself has been saying for years (and recently even in this thread) that
/usr/include/linuxand/usr/include/asmshould NOT EVER be symlinks to/usr/src/linuxI don't think Linus said that at all.
That is the problem. Linus has been saying that for years, but as I said, for some reason people refuse to listen. You're proving my point.
Quoted 3 lines
In fact, the first trees that
Linus made and distributed were done this way and have become the de-facto standard as a result of this.
Read <[email protected]> in which Linus says:
Quoted 3 lines
/usr/include/asmis a symlink to/usr/src/linux/include/asm, as in the original distribution but/usr/src/linuxis a 2.4.0-testX tree. With a 2.2.X source tree, it does not produce any warning.
I've asked glibc maintainers to stop the symlink insanity for the last few years now, but it doesn't seem to happen.
Basically, that symlink should not be a symlink. It's a symlink for historical reasons, none of them very good any more (and haven't been for a long time), and it's a disaster unless you want to be a C library developer. Which not very many people want to be.
The fact is, that the header files should match the library you link against, not the kernel you run on.
Also read <[email protected]> for more enlightenment. If you want to join a thread, please make sure that you have read all messages in it.
Mike.
Signature · 6 lines
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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Followup to: <[email protected]> By author: [email protected] (Miquel van Smoorenburg) In newsgroup: linux.dev.kernel
Quoted 8 lines
No. Even Linus himself has been saying for years (and recently even in this thread) that
/usr/include/linuxand/usr/include/asmshould NOT EVER be symlinks to/usr/src/linuxEverything in
/usr/includebelongs 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.
-hpa
Signature · 8 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
In article >[email protected]>,
Quoted 8 lines · H. Peter Anvin
Followup to: <[email protected]> By author: [email protected] (Miquel van Smoorenburg) In newsgroup: linux.dev.kernelQuoted 5 lines
No. Even Linus himself has been saying for years (and recently even in this thread) that
/usr/include/linuxand/usr/include/asmshould NOT EVER be symlinks to/usr/src/linux
Quoted 6 lines
Quoted 2 lines
Everything in
/usr/includebelongs 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.
Mike.
Signature · 6 lines
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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Followup to: <[email protected]> By author: [email protected] (Miquel van Smoorenburg) In newsgroup: linux.dev.kernel
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
Everything in
/usr/includebelongs 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.
Quoted 8 lines
Yes, but you can't mix&match anyway. For stuff like that you're probably best off by using a
talktokernel.cfile 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.
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.
-hpa
Signature · 8 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · In article <[email protected]> you [email protected] wrote:
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.
And IMHO to be able to do this, one should have to provide an explicit -I/usr/src/my-kernel/linux/include, it should not be the default.
/Christer
Signature · 6 lines
"Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 10 lines · [email protected] wrote:
Quoted 4 lines · In article <[email protected]> you [email protected] wrote:
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.
And IMHO to be able to do this, one should have to provide an explicit -I/usr/src/my-kernel/linux/include, it should not be the default.
I disagree. It makes life far too painful for the end user, for really no gain.
-hpa
Signature · 8 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · In article <[email protected]> you [email protected] writes:
Quoted 2 lines · [email protected] wrote:
And IMHO to be able to do this, one should have to provide an explicit -I/usr/src/my-kernel/linux/include, it should not be the default.
I disagree. It makes life far too painful for the end user, for really no gain.
The idea was to make a point, that #include <linux/xxx.h> really is a kernel/kernel aware application thing only. It ought to reduce the number of people who try to include kernel only stuff without knowing that it is a nono most of the time.
It isn't all that hard to add the following lines to the Makefiles for an application that needs the kernel includes:
KERNELDIR=/usr/src/linux
CFLAGS+=$(KERNELDIR)/include
And then standardise on /usr/src/linux as the directory where the kernel includes for the current kernel reside on a distribution. Those who compile multiple kernels on the same system should be savvy enough to do "KERNELDIR=/usr/src/my-kernel/linux make" or modify the Makefile.
/Christer
Signature · 6 lines
"Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
In article >[email protected]>,
Quoted 16 lines · H. Peter Anvin
Followup to: <[email protected]> By author: [email protected] (Miquel van Smoorenburg) In newsgroup: linux.dev.kernelQuoted 13 lines
Quoted 7 lines
Quoted 3 lines
Everything in
/usr/includebelongs 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.cfile that is compiled with -I/path/to/kernel/include while the rest of the daemon doesn't know about kernel internals.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Signature · 6 lines
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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Followup to: <[email protected]> By author: [email protected] (Miquel van Smoorenburg) In newsgroup: linux.dev.kernel
Quoted 6 lines
Why? As I said you can use a glue layer. Note that you still cannot mix
/usr/include/netand/usr/src/linux/include/netanyway, so clashes will always exist with the current system.
I agree it should probably be fixed.
A GLUE LAYER IS FREQUENTLY NOT AN OPTION, because you have no data types to carry around the semantic contents in. You really *DO* need to mix both types.
-hpa
Signature · 8 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
In article >[email protected]>,
Quoted 10 lines · H. Peter Anvin
Followup to: <[email protected]> By author: [email protected] (Miquel van Smoorenburg) In newsgroup: linux.dev.kernelQuoted 5 lines
Why? As I said you can use a glue layer. Note that you still cannot mix
/usr/include/netand/usr/src/linux/include/netanyway, so clashes will always exist with the current system.
I agree it should probably be fixed.A GLUE LAYER IS FREQUENTLY NOT AN OPTION,
No need to shout, I did say I agreed with you ;)
Quoted 3 lines
because you have no data
types to carry around the semantic contents in. You really *DO* need to mix both types.
Yes. So it should be fixed, right? Perhaps in 2.5 then we should look into:
- moving kernel headers around: linux/include now contains
o linux
o asm
o net
o scsi
o video
To make sure we _can_ use libc headers and kernel headers we must eliminate clashes. linux/include/net isn't the same as /usr/include/net, same goes for /usr/include/scsi etc. So it's probably best to move everything one level to:
o linux/kernel/*.h (this was most of linux/*.h)
o linux/public/*.h (contains public interfaces to the kernel)
o linux/asm/*.h
o linux/net/*.h
o linux/scsi/*.h
o linux/video/*.h
Hmm, perhaps that is not nessecary. If we're going to have a linux/public hierarchy, you wouldn't need the rest of the headers anyway, so they don't need to be moved. Cool ;)
- We need a script in /lib/modules/version/kernel-config that prints the CFLAGS used to compile that kernel on stdout to compile modules.
Now, I think that all of this has been mentioned before on this list, those are not completely my ideas. Somebody mentioned marking structures/defines/etc that need to be exported with a special comment so that a script could generate a set of headers with the public interfaces. That is about the same as the public/ idea, and perhaps a bit easier, since it wouldn't annoy the hell out of all those device driver writers that see the interface change again..
Mike.
Signature · 6 lines
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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · H. Peter Anvin
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.
Does this mean that automount has to be rebuilt for every kernel? And that we should be running /lib/modules/uname -r/sbin/automount.
It's sounds like it's an awful lot like a loadable module in how tightly it's tied to the kernel. And how a kernel change can break things horribly. How you have to be built against the one you're going to run against and not the one glibc was built against.
mrc
Signature · 9 lines
Mike Castle Life is like a clock: You can work constantly [email protected] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · In article <[email protected]> [email protected]…
Quoted 3 lines · H. Peter Anvin
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.
Quoted 7 lines
Does this mean that automount has to be rebuilt for every kernel? And that we should be running
/lib/modules/uname -r/sbin/automount.It's sounds like it's an awful lot like a loadable module in how tightly it's tied to the kernel. And how a kernel change can break things horribly. How you have to be built against the one you're going to run against and not the one glibc was built against.
It only means that the application will be built agains the kernel _interface_ that was present in that version of the kernel. And syscall/ioctl interfaces should never change, they can be added to, and relly old depreciated interfaces can be removed, but they should be stable for at least a few major kernel releases.
/Christer
Signature · 6 lines
"Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · On Tue, Aug 01, 2000 at 02:30:27AM -0000, [email protected] wrote:
Quoted 1 line · In article <[email protected]> [email protected]…
On Mon, Jul 31, 2000 at 03:13:55PM -0700, H. Peter Anvin wrote:
[hpa talks about apps, like automount, needing kernel headers for versions being ran and version glibc was built againt]
[I ask about kernel specific versions of binaries]
Quoted 5 lines
It only means that the application will be built agains the kernel _interface_ that was present in that version of the kernel. And syscall/ioctl interfaces should never change, they can be added to, and relly old depreciated interfaces can be removed, but they should be stable for at least a few major kernel releases.
If they are so stable, then why does it matter which version of the kernel glibc was built against and why aren't those kernel headers good enough to accomplish what automounter needs?
mrc
Signature · 9 lines
Mike Castle Life is like a clock: You can work constantly [email protected] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Followup to: <[email protected]> By author: Mike Castle <[email protected]> In newsgroup: linux.dev.kernel
Quoted 5 lines
If they are so stable, then why does it matter which version of the kernel glibc was built against and why aren't those kernel headers good enough to accomplish what automounter needs?
They usually are just fine. However, if the automount protocol is updated, we don't want to *have* to sit through a full glibc release cycle.
-hpa
Signature · 8 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
In article >[email protected]>,
Quoted 4 lines · H. Peter Anvin
Followup to: <[email protected]> By author: Mike Castle <[email protected]> In newsgroup: linux.dev.kernelQuoted 1 line
Quoted 8 lines
Quoted 4 lines
If they are so stable, then why does it matter which version of the kernel glibc was built against and why aren't those kernel headers good enough to accomplish what automounter needs?
They usually are just fine. However, if the automount protocol is updated, we don't want to *have* to sit through a full glibc release cycle.
It sounds like autofs should come with it's own copy of the needed definitions and header files then. Now if there were 20 applications all using the autofs interface to the kernel then it would be different, but if it's just one standard implementation..
Mike.
Signature · 6 lines
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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Followup to: <[email protected]> By author: [email protected] (Miquel van Smoorenburg) In newsgroup: linux.dev.kernel
Quoted 10 lines
Quoted 4 lines
They usually are just fine. However, if the automount protocol is updated, we don't want to *have* to sit through a full glibc release cycle.
It sounds like autofs should come with it's own copy of the needed definitions and header files then. Now if there were 20 applications all using the autofs interface to the kernel then it would be different, but if it's just one standard implementation..
Two, at least (amd uses it as well, now.) There are a number of similar interface issues, though, and the fact remains this is at best an ad hoc solution.
-hpa
Signature · 8 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Followup to: <[email protected]> By author: Mike Castle <[email protected]> In newsgroup: linux.dev.kernel
Quoted 9 lines · H. Peter Anvin
Quoted 3 lines
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.
Does this mean that automount has to be rebuilt for every kernel? And that we should be running
/lib/modules/uname -r/sbin/automount.
No, it doesn't.
-hpa
Signature · 8 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Miquel van Smoorenburg
modules that use
include/net? The one in the kernel source is very, very different from the one in glibc .. so you have to compile with -I/path/to/kernel/include _anyway_
Maybe just make it mandatory that every time you upgrade the kernel, you should rebuild the entire system.
mrc
Signature · 9 lines
Mike Castle Life is like a clock: You can work constantly [email protected] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
In article >[email protected]>,
Quoted 7 lines · Mike Castle
Quoted 3 lines · Miquel van Smoorenburg
modules that use
include/net? The one in the kernel source is very, very different from the one in glibc .. so you have to compile with -I/path/to/kernel/include _anyway_Maybe just make it mandatory that every time you upgrade the kernel, you should rebuild the entire system.
Well for modules, yes, that is pretty much the case isn't it ?
Mike.
Signature · 6 lines
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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 11 lines · Miquel van Smoorenburg
In article >[email protected]>,
Quoted 7 lines · Mike Castle
Quoted 3 lines · Miquel van Smoorenburg
modules that use
include/net? The one in the kernel source is very, very different from the one in glibc .. so you have to compile with -I/path/to/kernel/include _anyway_Maybe just make it mandatory that every time you upgrade the kernel, you should rebuild the entire system.
Well for modules, yes, that is pretty much the case isn't it ?
I was being facetious. I meant not only modules, but libc, and {/usr,}/{s,}bin as well.
mrc
Signature · 9 lines
Mike Castle Life is like a clock: You can work constantly [email protected] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines
Quoted 2 lines · [email protected] (Jesse Pollard) wrote:
That way the "uname -r" command could be used to set a symbolic link to point to the correct include files at boot time (or install time).
Quoted 1 line · Kai Henningsen
Correct for what?
correct for building kernel modules for /lib/include/$KERNEL_VER. that's how i've used /lib/include for some time,
when needing to generate oodles of different versions of a kernel module under active development, without necessarily having oodles of /usr/src/linux-$KERNEL_VER trees.
i just propagate /boot/*$KERNEL_VER* and /lib/{modules,include}/$KERNEL_VER as one tarball fully describing the environment, to anything i'm even thinking of building on.
i do admit to maintaining boot-time /usr/include/{linux,asm} ---> /lib/include/$(uname -r)/{linux,asm} symlinks to get a consistent usermode include tree, but it's always worried me.
The interesting parts of /usr/include are always the bleeding edge which *hasn't* made it into glibc-blessed namespace yet.
I'm hoping some clear methodology will arise out of this bickering which will allow stable apps to build against a static tree, with gcc-bleeding-edge resorted to as a fallback.
[exec gcc -I/lib/include/${KERNEL_VER:-$(uname -r)} "$@"] Ideally, binaries produced in this way would be tagged with their dependance on version>=xx.yy.zz obvious, so they're not confused with the stable builds, and can be ported to glibc-blessed-namespace when new features propagate there.
^..^
(oo)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/