[PATCH] include/linux/coda.h

[PATCH] include/linux/coda.h

[Me]

[-- Attachment #1: Type: text/plain, Size: 174 bytes --]

 Coda.h assumes that __KERNEL__ can only be defined if __linux__ is, which is 
painfully false. This allows the kernel compile to get farther on my token 
FreeBSD box.

-Ryan

[-- Attachment #2: crosscompile.diff --]
[-- Type: text/x-c, Size: 516 bytes --]

--- linux/include/linux/coda.h	Wed Apr 25 16:18:54 2001
+++ linux/include/linux/coda.h	Mon May 21 21:19:21 2001
@@ -100,6 +100,10 @@
 
 #if defined(__linux__)
 #define cdev_t u_quad_t
+#else
+#define cdev_t dev_t
+#endif
+
 #ifndef __KERNEL__
 #if !defined(_UQUAD_T_) && (!defined(__GLIBC__) || __GLIBC__ < 2)
 #define _UQUAD_T_ 1
@@ -108,9 +112,6 @@
 #else /*__KERNEL__ */
 typedef unsigned long long u_quad_t;
 #endif /* __KERNEL__ */
-#else
-#define cdev_t dev_t
-#endif
 
 #ifdef __CYGWIN32__
 struct timespec {

Re: [PATCH] include/linux/coda.h

[Jan Harkes]

On Mon, May 21, 2001 at 09:24:20PM -0700, Me wrote:
>  Coda.h assumes that __KERNEL__ can only be defined if __linux__ is, which is 
> painfully false. This allows the kernel compile to get farther on my token 
> FreeBSD box.
> 
> -Ryan

Are you trying to compile a Linux kernel on a FreeBSD machine, or is
this a bug in the Coda kernel module in the FreeBSD tree?

Jan

Re: [PATCH] include/linux/coda.h

[Me]

On Tuesday 22 May 2001 06:18, you wrote:
> Are you trying to compile a Linux kernel on a FreeBSD machine, or is
> this a bug in the Coda kernel module in the FreeBSD tree?
>
Sorry, I should've been more specific. I'm trying to compile the Linux kernel 
(2.4.5pre3) on a FreeBSD machine, which actually works quite well with this 
patch applied. This is the only place in the core that FreeBSD gets hung up 
on (init/main.c seems to include it unconditionally). Some drivers may still  
make incorrect assumptions about __linux__ being defined, though.

-Ryan

Re: [PATCH] include/linux/coda.h

[Alan Cox]

> Sorry, I should've been more specific. I'm trying to compile the Linux kernel 
> (2.4.5pre3) on a FreeBSD machine, which actually works quite well with this 
> patch applied. This is the only place in the core that FreeBSD gets hung up 

Why is your cross compiler outputting different symbols to a linux native 
compiler ?

> on (init/main.c seems to include it unconditionally). Some drivers may still  
> make incorrect assumptions about __linux__ being defined, though.

If __linux__ is not defined by the cross compiler, then the cross compiler
is broken. A cross compiler has the same environment as the native compiler
for the target. The only stuff that should break (well should as in might) is 
tools native built

Or am I misunderstanding the report ?

Re: [PATCH] include/linux/coda.h

[David Woodhouse]

alan@lxorguk.ukuu.org.uk said:
>  Why is your cross compiler outputting different symbols to a linux
> native  compiler ?

> If __linux__ is not defined by the cross compiler, then the cross
> compiler is broken. A cross compiler has the same environment as the
> native compiler for the target. The only stuff that should break (well
> should as in might) is  tools native built

> Or am I misunderstanding the report ?

Why use a cross compiler? With the obvious exception of UML, the Linux
kernel is not a Linux executable, so why should it need to be compiled with
a compiler which targets such? 

The kernel compiles quite happily with compilers which aren't targetted 
specifically at Linux -- the CODA compatibility cruft being the one 
exception. I often just comment out the CODA includes from <linux/fs.h> to 
get round the same problem.

--
dwmw2

Re: [PATCH] include/linux/coda.h

[Jan Harkes]

On Tue, May 22, 2001 at 04:57:24PM +0100, David Woodhouse wrote:
> The kernel compiles quite happily with compilers which aren't targetted 
> specifically at Linux -- the CODA compatibility cruft being the one 
> exception. I often just comment out the CODA includes from <linux/fs.h> to 
> get round the same problem.

Well, the original idea for having all that compatibility cruft in
coda.h was that the identical header could be used both by userspace,
and as part of the kernel code of all Coda ports.

But with problems like these popping up and the silly thing is just
turning into an unmaintainable mess of #ifdef bloat.

#include <linux/coda.h> can be taken out of linux/fs.h when I change a
few lines of code. In fact with those changes all Coda related headers
can be moved from include/linux/ to fs/coda/, although coda.h contains
the 'exported interface' and should probably remain in include/linux.

At least this will solve your problem as long as Coda isn't compiled
into the kernel, but not the reported problem of compiling a Linux
kernel on a different (Coda supported) OS without using a properly
configured cross-compiler.

I will try cleaning things up by having a common 'coda.h' for all
platforms (and userspace) and platform specific 'coda_types.h' files
which define missing types and such. It would definitely get rid of a
lot of the bloat, and probably make things somewhat easier to maintain.

Jan

btw. Coda is not an acronym, no need to capitalize it.

Re: [PATCH] include/linux/coda.h

[Ryan Cumming]

On Tue, 22 May 2001, Alan Cox wrote:

> If __linux__ is not defined by the cross compiler, then the cross compiler
> is broken. A cross compiler has the same environment as the native compiler
> for the target. The only stuff that should break (well should as in might) is
> tools native built
>
> Or am I misunderstanding the report ?

It is not a cross compiler, it is the FreeBSD native gcc. As I understood
it, Linux is a self contained project and should be targetting the
native platform, not Linux on that platform. A cross compiler should
not be needed unless one is building for another CPU.

The coda.h file was doing something along the lines of:

#ifdef __linux__
#ifdef __KERNEL__
/* Define things */
#endif
#endif

When compiling the kernel under FreeBSD, __KERNEL__ is defined, but
__linux__ is not. I think this is an error on the part of the header file,
because on non-Linux build environments, which would otherwise compile the
Linux kernel correctly, do not have __linux__ defined.

However, not many people will probably find much use in compiling the
kernel on other platforms, so if you think this isn't worth inclusion, I
totally understand. I'm in the process of porting UML to FreeBSD, and
having this patch in the tree would make my job slightly easier.

-Ryan

UML cross-platform build problems (was Re: [PATCH] include/linux/coda.h)

[Jan Harkes]

On Tue, May 22, 2001 at 09:40:19AM -0700, Ryan Cumming wrote:
> On Tue, 22 May 2001, Alan Cox wrote:
> 
> > If __linux__ is not defined by the cross compiler, then the cross compiler
> > is broken. A cross compiler has the same environment as the native compiler
> > for the target. The only stuff that should break (well should as in might) is
> > tools native built
> >
> > Or am I misunderstanding the report ?
> 
> It is not a cross compiler, it is the FreeBSD native gcc. As I understood
> it, Linux is a self contained project and should be targetting the
> native platform, not Linux on that platform. A cross compiler should
> not be needed unless one is building for another CPU.

The problem is that the same coda.h header is also used as part of the
FreeBSD kernel to build a Coda kernel module. Both Linux and FreeBSD
have different include and typedef requirements for their kernel code.

There is no way for an identical coda.h header to recognize whether it
is built as part of the FreeBSD kernel or as part of a (UML) Linux
kernel, except if the parts that are OS dependent are not part of the
same header.

I agree that a UML kernel on FreeBSD should be a native binary and not
cross-compiled. However, this could be an UML specific problem and
-D__linux__ should be added to CFLAGS in arch/uml/Makefile as all
drivers and filesystems that are developed for different platforms and
share parts of their code are possibly affected.

Jan

Re: [PATCH] include/linux/coda.h

[Alan Cox]

> When compiling the kernel under FreeBSD, __KERNEL__ is defined, but
> __linux__ is not. I think this is an error on the part of the header file,
> because on non-Linux build environments, which would otherwise compile the
> Linux kernel correctly, do not have __linux__ defined.

Thats a problem with your compiler setup.

> However, not many people will probably find much use in compiling the
> kernel on other platforms, so if you think this isn't worth inclusion, I
> totally understand. I'm in the process of porting UML to FreeBSD, and
> having this patch in the tree would make my job slightly easier.

Teaching your gcc to do -D__linux__ would be cleaner and also catch the
zillion other cases that simply came out wrong instead of erroring

One shell script for your CC and off you go

Re: UML cross-platform build problems (was Re: [PATCH] include/linux/coda.h)

[Jeff Dike]

jaharkes@cs.cmu.edu said:
> I agree that a UML kernel on FreeBSD should be a native binary and not
> cross-compiled. However, this could be an UML specific problem and
> -D__linux__ should be added to CFLAGS in arch/uml/Makefile

Exactly.  Don't be shy about fiddling CFLAGS in UML-specific Makefiles.  This 
is already done quite a bit (-D__i386__ and the construction of userspace 
CFLAGS are examples).

This is very UML-specific, so there's no reason to bother the rest of the 
kernel (unless, of course, you find a bug that could affect other ports).

				Jeff

Re: [PATCH] include/linux/coda.h

[Thomas Dodd]

Ryan Cumming wrote:
> When compiling the kernel under FreeBSD, __KERNEL__ is defined, but
> __linux__ is not. I think this is an error on the part of the header file,
> because on non-Linux build environments, which would otherwise compile the
> Linux kernel correctly, do not have __linux__ defined.
> 
> However, not many people will probably find much use in compiling the
> kernel on other platforms, so if you think this isn't worth inclusion, I

hmmm...

building for:
SPARC under Solaris
PPC under BeOS
PA-RISC under HP-UX
M68k under HP-UX

I'd really like the last one.
I have a HP, M68k box I'd like to run
linux on and I've not seen a M68K distro
yet. But I haven't had time to try it yet
either.

	-Thomas