Re: 2.1.126 still no sparc64 autofs

Matthias Welwarsky (matze@stud.fbi.fh-darmstadt.de)
Mon, 16 Nov 1998 22:26:52 +0100


Jamie Lokier wrote:
>
> On Sat, Nov 14, 1998 at 01:45:16PM -0500, Rich Sahlender wrote:
> > H. Peter Anvin wrote:
> > > Why is the "long" a different size in kernel and user space? That
> > > seems buggy. It's an easy thing to fix, but it seems like the Wrong
> > > Thing[TM].
> >
> > I tend to agree it's buggy. I would expect the long to generate a 32
> > bit int even in the 64 bit kernel space unless you specifically ask
> > for a 64 bit long .ie. suns 'long long'. This would keep things
> > downward/backward compatible.
>
> A big problem is that there are a number of places in the kernel that
> assume sizeof(long) == sizeof(void *). Mostly to do with page tables
> and I/O address remapping, a few to do with overloading struct elements
> by kludgy casts.
>

Hm, at least for Alpha and Intel sizeof(void*) == sizeof(long).
Shouldn't this apply for sparc64, too? If not, theres inconsistency
between the different 64bit archs in gcc/egcs. That would be real
*ouch*. Most of the time problems arise because people think sizeof(int)
== sizeof(long) == sizeof(void *). However, symbolic types should be
used in structs shared between userspace and kernel. I`d rather say that
the problem is because the userland compile process for autofs uses
other header files than the kernel - normal case with glibc.

Gruss,
Matthias

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