2000-07-31 20:57:03

by Miquel van Smoorenburg

[permalink] [raw]
Subject: Re: RLIM_INFINITY inconsistency between archs

In article >[email protected]>,
Richard B. Johnson <[email protected]> wrote:
> /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.

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.
--
Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.


2000-07-31 21:29:48

by Richard B. Johnson

[permalink] [raw]
Subject: Re: RLIM_INFINITY inconsistency between archs

On 31 Jul 2000, Miquel van Smoorenburg wrote:

> In article >[email protected]>,
> Richard B. Johnson <[email protected]> wrote:
> > /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.
>
> 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
>

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.

> Everything in /usr/include belongs 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.

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

We don't use /usr/src/linux/include. As stated, the include files
are referenced from /usr/include.


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



2000-08-01 02:08:12

by Mike Castle

[permalink] [raw]
Subject: Re: RLIM_INFINITY inconsistency between archs

On Mon, Jul 31, 2000 at 09:15:43PM +0000, Miquel van Smoorenburg wrote:
> 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
--
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