Fix for include/linux/fs.h in 2.4.0 kernels

Fix for include/linux/fs.h in 2.4.0 kernels

[Jocelyn Mayer]

I had some problems while compiling some applications 
with the 2.4.0 kernel.
The problem was a conflict between string.h from the libc
and the one from the kernel, which is included in fs.h
So, using <string.h> and <linux/fs.h> at the same time
brings some conflicts.
It seems to me that <linux/string.h> should not be apparent 
from user mode, so I did this patch:

--- fs.h-orig   Fri Feb  2 23:55:35
2001                                                                                                                                      
+++ fs.h        Fri Feb  2 21:26:05
2001                                                                                                                                      
@@ -20,7 +20,7
@@                                                                                                                                                             
 #include
<linux/stat.h>                                                                                                                                                      
 #include
<linux/cache.h>                                                                                                                                                     
 #include
<linux/stddef.h>                                                                                                                                                    
-#include
<linux/string.h>                                                                                                                                                    
+/*  #include <linux/string.h>
*/                                                                                                                                             
                                                                                                                                                                              
 #include
<asm/atomic.h>                                                                                                                                                      
 #include
<asm/bitops.h>                                                                                                                                                      
@@ -190,6 +190,7
@@                                                                                                                                                           
                                                                                                                                                                              
 #include
<asm/semaphore.h>                                                                                                                                                   
 #include
<asm/byteorder.h>                                                                                                                                                   
+#include
<linux/string.h>                                                                                                                                                    
                                                                                                                                                                              
 extern void update_atime (struct inode
*);                                                                                                                                   
 #define UPDATE_ATIME(inode) update_atime
(inode)                                                                                                                             
 

Like this, the #include <linux/string.h> is "protected" 
by a #ifdef __KERNEL__, so I don't have any conflict any more.

I recompiled my kernel without any problem since I did that patch.

Regards.

Jocelyn Mayer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Keith Owens]

On Sat, 03 Feb 2001 00:04:16 +0100, 
Jocelyn Mayer <jocelyn.mayer@netgem.com> wrote:
>I had some problems while compiling some applications 
>with the 2.4.0 kernel.
>The problem was a conflict between string.h from the libc
>and the one from the kernel, which is included in fs.h

Rule 1.  Applications must not include include kernel headers directly.

Rule 2. Any glibc that has a symlink from /usr/include/{linux,asm} to
/usr/src/linux/include/{linux,asm} is wrong.

Relying on /usr/include/{linux,asm} always pointing at the current
kernel source is broken as designed.  /usr/include/{linux,asm} must be
real directories that are shipped as part of glibc, not symlinks to
some random version of the kernel.  Fix /usr/include.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Frédéric L. W. Meunier]

Keith Owens wrote:

> Rule 2. Any glibc that has a symlink from
> /usr/include/{linux,asm} to /usr/src/linux/include/{linux,asm}
> is wrong.

Such symlinks are created by the user.

> Relying on /usr/include/{linux,asm} always pointing at the
> current kernel source is broken as designed.

>From glibc 2.2.1 FAQ:

2.17.   I have /usr/include/net and /usr/include/scsi as symlinks
	into my Linux source tree.  Is that wrong?

{PB} This was necessary for libc5, but is not correct when
using glibc. Including the kernel header files directly in user
programs usually does not work (see question 3.5). glibc
provides its own <net/*> and <scsi/*> header files to replace
them, and you may have to remove any symlink that you have in
place before you install glibc. However, /usr/include/asm and
/usr/include/linux should remain as they were.

Keith, are you saying that glibc is wrong?

3.5.    On Linux I've got problems with the declarations in Linux
	kernel headers.

{UD,AJ} On Linux, the use of kernel headers is reduced to the
minimum. This gives Linus the ability to change the headers
more freely. Also, user programs are now insulated from changes
in the size of kernel data structures.

For example, the sigset_t type is 32 or 64 bits wide in the
kernel. In glibc it is 1024 bits wide. This guarantees that
when the kernel gets a bigger sigset_t (for POSIX.1e realtime
support, say) user programs will not have to be recompiled.
Consult the header files for more information about the
changes.

Therefore you shouldn't include Linux kernel header files
directly if glibc has defined a replacement. Otherwise you
might get undefined results because of type conflicts.

> /usr/include/{linux,asm} must be real directories that are
> shipped as part of glibc, not symlinks to some random version
> of the kernel. Fix /usr/include.

But make install didn't create them. I built 2.2 and 2.2.1.

-- 
Frédéric L. W. Meunier - http://www.pervalidus.net/
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Brian May]

>>>>> "Frédéric" == Frédéric L W Meunier <0@pervalidus.net> writes:

    Frédéric> Keith Owens wrote:
    >> Rule 2. Any glibc that has a symlink from
    >> /usr/include/{linux,asm} to /usr/src/linux/include/{linux,asm}
    >> is wrong.

    Frédéric> Such symlinks are created by the user.

    >> Relying on /usr/include/{linux,asm} always pointing at the
    >> current kernel source is broken as designed.

    Frédéric> From glibc 2.2.1 FAQ:

    Frédéric> 2.17.  I have /usr/include/net and /usr/include/scsi as
    Frédéric> symlinks into my Linux source tree.  Is that wrong?

    Frédéric> {PB} This was necessary for libc5, but is not correct
    Frédéric> when using glibc. Including the kernel header files
    Frédéric> directly in user programs usually does not work (see
    Frédéric> question 3.5). glibc provides its own <net/*> and
    Frédéric> <scsi/*> header files to replace them, and you may have
    Frédéric> to remove any symlink that you have in place before you
    Frédéric> install glibc. However, /usr/include/asm and
    Frédéric> /usr/include/linux should remain as they were.

    Frédéric> Keith, are you saying that glibc is wrong?

You both seem to be saying the same thing: that symlinks for
/usr/include/{linux,asm} are wrong.

Why try to argue when you agree?

(Debian does this right; last I heard Red-Hat didn't)
-- 
Brian May <bam@snoopy.apana.org.au>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Keith Owens]

On Sat, 3 Feb 2001 00:49:26 -0200, 
Fr d ric L. W. Meunier <0@pervalidus.net> wrote:
>Keith Owens wrote:
>> Relying on /usr/include/{linux,asm} always pointing at the
>> current kernel source is broken as designed.
>
>From glibc 2.2.1 FAQ:
>
>2.17.   I have /usr/include/net and /usr/include/scsi as symlinks
>	into my Linux source tree.  Is that wrong?
>
>{PB} This was necessary for libc5, but is not correct when
>using glibc. Including the kernel header files directly in user
>programs usually does not work (see question 3.5). glibc
>provides its own <net/*> and <scsi/*> header files to replace
>them, and you may have to remove any symlink that you have in
>place before you install glibc. However, /usr/include/asm and
>/usr/include/linux should remain as they were.
>
>Keith, are you saying that glibc is wrong?

Not me, Linus says that glibc is wrong.

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

http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html
for the rest of Linus's reasons.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Brian May]

>>>>> "Keith" == Keith Owens <kaos@ocs.com.au> writes:

    >> {PB} This was necessary for libc5, but is not correct when
    >> using glibc. Including the kernel header files directly in user
    >> programs usually does not work (see question 3.5). glibc
    >> provides its own <net/*> and <scsi/*> header files to replace
    >> them, and you may have to remove any symlink that you have in
    >> place before you install glibc. However, /usr/include/asm and
    >> /usr/include/linux should remain as they were.
    >> 
    >> Keith, are you saying that glibc is wrong?

    Keith> Not me, Linus says that glibc is wrong.

    Keith>   "I've asked glibc maintainers to stop the symlink
    Keith> insanity for the last few years now, but it doesn't seem to
    Keith> happen.

    Keith>   Basically, that symlink should not be a symlink.  It's a
    Keith> symlink for historical reasons, none of them very good any
    Keith> more (and haven't been for a long time), and it's a
    Keith> disaster unless you want to be a C library developer.
    Keith> Which not very many people want to be.

    Keith>   The fact is, that the header files should match the
    Keith> library you link against, not the kernel you run on."


I read Keith's response as: the symlink is wrong.
I read the glib FAQ as:     the symlink is wrong.
I read Linus' response as:  the symlink is wrong.

Who is contradicting who here?

(perhaps that last sentence in the glibc FAQ is confusing, however the
rest of it clearly says that glibc contains its own version of those
files, and a symlink should *not* be used. I think the part "[...] you
may have to remove any symlink [...]" is clear enough).
-- 
Brian May <bam@snoopy.apana.org.au>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Brian Wellington]

On 3 Feb 2001, Brian May wrote:

> >>>>> "Keith" == Keith Owens <kaos@ocs.com.au> writes:
> 
>     >> {PB} This was necessary for libc5, but is not correct when
>     >> using glibc. Including the kernel header files directly in user
>     >> programs usually does not work (see question 3.5). glibc
>     >> provides its own <net/*> and <scsi/*> header files to replace
>     >> them, and you may have to remove any symlink that you have in
>     >> place before you install glibc. However, /usr/include/asm and
>     >> /usr/include/linux should remain as they were.
>     >> 
>     >> Keith, are you saying that glibc is wrong?
> 
>     Keith> Not me, Linus says that glibc is wrong.
> 
>     Keith>   "I've asked glibc maintainers to stop the symlink
>     Keith> insanity for the last few years now, but it doesn't seem to
>     Keith> happen.
> 
>     Keith>   Basically, that symlink should not be a symlink.  It's a
>     Keith> symlink for historical reasons, none of them very good any
>     Keith> more (and haven't been for a long time), and it's a
>     Keith> disaster unless you want to be a C library developer.
>     Keith> Which not very many people want to be.
> 
>     Keith>   The fact is, that the header files should match the
>     Keith> library you link against, not the kernel you run on."
> 
> 
> I read Keith's response as: the symlink is wrong.
> I read the glib FAQ as:     the symlink is wrong.
> I read Linus' response as:  the symlink is wrong.
> 
> Who is contradicting who here?
> 
> (perhaps that last sentence in the glibc FAQ is confusing, however the
> rest of it clearly says that glibc contains its own version of those
> files, and a symlink should *not* be used. I think the part "[...] you
> may have to remove any symlink [...]" is clear enough).

No, it clearly says that glibc contains its own versions of the net/* and
scsi/* files, and that /usr/include/asm and /usr/include/linux should
remain as they were.  Since they were symlinks in libc5 (which is what
'originally' seems to be referring to), they should still be symlinks.

Brian (who really doesn't care either way)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Brian May]

>>>>> "Brian" == Brian Wellington <bwelling@xbill.org> writes:

    Brian> No, it clearly says that glibc contains its own versions of
    Brian> the net/* and scsi/* files, and that /usr/include/asm and
    Brian> /usr/include/linux should remain as they were.  Since they
    Brian> were symlinks in libc5 (which is what 'originally' seems to
    Brian> be referring to), they should still be symlinks.

Oh I see now.

Sorry for any confusion caused.
-- 
Brian May <bam@snoopy.apana.org.au>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Alan Cox]

> kernel source is broken as designed.  /usr/include/{linux,asm} must be
> real directories that are shipped as part of glibc, not symlinks to
> some random version of the kernel.  Fix /usr/include.

You need to fix the kernel headers too - libc5 doesnt work otherwise
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Graham Murray]

Keith Owens <kaos@ocs.com.au> writes:

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

So what is your advice?  Would the "correct" action be to take a
snapshot of the appropriate kernel directories against which glibc is
built? (ie to copy the directories (or those files needed) to
/usr/include/asm and /usr/include/linux)

On the other hand, if you are building "system level" tools (eg which
communicate with device drivers directly using IOCTLs) you may need to
use the kernel header files, in which case I suppose you should
include them from the kernel source tree not /usr/include.

In both case, I think the problem is not so much in code which you
write yourself (where you control include paths etc) but in building
3rd party applications which may not have used the "correct" include
paths and therefore will not build "out of the box".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Keith Owens]

On 03 Feb 2001 08:48:54 +0000, 
Graham Murray <graham@barnowl.demon.co.uk> wrote:
>So what is your advice?  Would the "correct" action be to take a
>snapshot of the appropriate kernel directories against which glibc is
>built? (ie to copy the directories (or those files needed) to
>/usr/include/asm and /usr/include/linux)

This has all been thrashed out before.  Read the threads

http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg18256.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Graham Murray]

Keith Owens <kaos@ocs.com.au> writes:

> This has all been thrashed out before.  Read the threads
> 
> http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg18256.html

I don't think that these address my question. I was asking about when
building (upgrading) glibc from source. I believe that the glibc
headers are "derived" from the kernel against which it is built. So,
irrespective of what the glibc maintainers do, would it be advisable
for the user to remove the symlinks and copy the directories from the
kernel tree and into /usr/include?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fix for include/linux/fs.h in 2.4.0 kernels

[Keith Owens]

On 03 Feb 2001 10:09:39 +0000, 
Graham Murray <graham@barnowl.demon.co.uk> wrote:
>Keith Owens <kaos@ocs.com.au> writes:
>> This has all been thrashed out before.  Read the threads
>> 
>> http://www.mail-archive.com/linux-kernel@vger.rutgers.edu/2000-month-07/msg04096.html
>> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg18256.html
>
>I don't think that these address my question. I was asking about when
>building (upgrading) glibc from source. I believe that the glibc
>headers are "derived" from the kernel against which it is built.

That way everybody builds a different glibc.  Does that strike you as a
good idea?  glibc should be shipped with standard include files.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/