Followup to: <[email protected]>
By author: [email protected] (Miquel van Smoorenburg)
In newsgroup: linux.dev.kernel
>
> 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.
>
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
--
<[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
On Mon, Jul 31, 2000 at 03:13:55PM -0700, H. Peter Anvin wrote:
> 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
--
Mike Castle Life is like a clock: You can work constantly
[email protected] and be right all the time, or not work at all
http://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
In article <[email protected]> [email protected] wrote:
>On Mon, Jul 31, 2000 at 03:13:55PM -0700, H. Peter Anvin wrote:
>> 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.
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
--
"Just how much can I get away with and still go to heaven?"
On Tue, Aug 01, 2000 at 02:30:27AM -0000, [email protected] wrote:
> In article <[email protected]> [email protected] wrote:
> >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]
> 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
--
Mike Castle Life is like a clock: You can work constantly
[email protected] and be right all the time, or not work at all
http://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