[klibc] [PATCH] Fix the build for utils/fstype.h

Russell King rmk at arm.linux.org.uk
Tue Apr 29 00:37:43 PDT 2003


On Mon, Apr 28, 2003 at 03:32:03PM -0700, H. Peter Anvin wrote:
> H. Peter Anvin wrote:
> > Bryan O'Sullivan wrote:
> > 
> >>Another post-2.5.68 one.  The cramfs header defines u8, so we must quiet
> >>it down.
> >>
> >>	<b
> >>
> >>diff -Nru a/utils/fstype.c b/utils/fstype.c
> >>--- a/utils/fstype.c	Mon Apr 28 15:10:56 2003
> >>+++ b/utils/fstype.c	Mon Apr 28 15:10:56 2003
> >>@@ -19,7 +19,9 @@
> >> #include <asm/byteorder.h>
> >> 
> >> #include <linux/romfs_fs.h>
> >>+#define __KERNEL__
> >> #include <linux/cramfs_fs.h>
> >>+#undef __KERNEL__
> >> #include <linux/minix_fs.h>
> >> #include <linux/ext2_fs.h>
> >> #include "ext3_fs.h"
> >>
> > 
> > No way I'm letting this crap into the tree.  Rather, I'd like to push
> > the fix into the kernel header, especially if this is a new phenomenon.
> >  The correct fix is to change u8 -> __u8 in the header.
> > 
> 
> Of course, one could definitely argue over if we should be including
> these kinds of headers in a utility program at all, but I suspect that's
> a losing battle.

Since klibc was supposed to be part of the kernel tarball, there was
absolutely no point in duplicating the filesystem data structures twice
in the same tarball.

However, since the future of klibc as part of the kernel tarball is
looking uncertain, if it remains external, it would probably make sense
to duplicate these structures.  ext3_fs is already an example where the
current kernel tarball headers don't like being included.  I believe
reiserfs was also an issue at one point as well.

-- 
Russell King (rmk at arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html



More information about the klibc mailing list