Andi Kleen wrote:
>Crispin Cowan <crispin@wirex.com> writes:
>
>
>>Could you elaborate on why this is a sign of trouble, design wise?
>>
>>
>David refers to the 32bit emulation issues. Some ports have a 64bit
>kernel, but support 64bit and 32bit userland (e.g. ia64 or x86-64).
>Some ports even only have 32bit userland but 64bit kernel (like sparc64 or
>mips64)
>
Thank you very much for clarifying.
>The 32bit and the 64bit worlds have different data types. Structure
>layout are different. To handle this the kernel has an emulation
>layer that converts the arguments of ioctls and system calls between
>32bit and 64bit.
>
>This emulation layer sits at the 'edge' of the kernel. For example
>to convert an ioctl it first figures out the ioctl, converts it
>then reissues the same ioctl internally with 64bit arguments. When
>the ioctl returns outgoing arguments are converted too as needed.
>
>For this to work all data structures need to be transparent.
>The emulation layer needs to have a way to figure out what and
>how to convert without looking at internal state in the kernel.
>Otherwise it cannot do its job.
>
>Without working emulation sparc64 won't work and David will be unhappy.
>
I'm all for 64-bit support, and for easy transition from 32 to 64 bits.
Really: I was around to watch the pain of transition from 16 bits to 32
bits, and I'm thrilled to see people taking the problem more seriously
this time.
So: does it help to specify that the sys_security arguments be (say)
"unsigned int"? Then you can just zero-pad them, or truncate them.
And even if the 32bit emulation layer doesn't perfectly translate the
sys_security arguments: that just breaks LSM modules. It would not
surprise me that something like an application trying to talk to a
security module might not cleanly port from 32 to 64 bits. By carefully
stating the assumptions (clean data types) most of these problems should
be addressed.
I don't get why this is a hard problem.
Crispin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:40 EST