Phil,
On Tue, Feb 14, 2006 at 12:57:55AM +0600, Philip Mucci wrote:
> Stefane,
>
> I know this is ugly, but what about in the user code checking the arch?
> Is it not true that if a kernel is running 64 bit, it has the 64 tagged
> on the the end of the arch? i.e. mips64, ppc64, x86_64?
>
> The other solution would be to add am information call to the API, like
> perfctr has. This would export the processor type along with other
> feature bits, including the number of bits of the IP.
>
The problem is at compile time and not so much at runtime.
Take a kernel struct that is shared with user (i.e., passed through syscall)
that has the following layout:
struct foo {
unsigned long bar;
int dummy;
};
For a 64-bit app on a 64-bit OS OR a 32-bit app on a 32-bit OS, this works
perfectly.
For a 32-bit on a 64-bit OS, there is a problem, the 32-bit app must be compiled
with the following definition instead:
struct foo {
unsigned long long bar;
int dummy;
};
to share the struct with the 64-bit OS. An application compile with the above
struct, would not work when run on a 32-bit OS.
So I think that we need to replace all unsigned long, size_t, void * by uint64_t
to make sure this works either way. It is overkill on pure 32-bit but ensures
that the application can be migrated over to a 64-bit OS without the need for
special recompilation.
--
-Stephane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
