Brian Gerst wrote:
> Do we really need another syscall interface for this? If we really do,
> then the syscall tables should be seperate. Otherwise, calling a 32-bit
> syscall with syscall64 leaves %edx with random data.
-- Why would someone randomly call a "C" function implemented to return an 'int' as a 'long long'? 1) They must be running w/o type checking turned on, and 2) it's just erroneous/bad code.They are separate calls, separate functions, separate type definitions. None of this would affect previous code -- no one should "change" to the new 64 bit interface for any existing function.
> > However, I think that this syscall should be implemented by passing a > pointer and using put_user() to return it to user space, at least on > 32-bit architectures. > Other 32-bit arches may not have multiple ways to > enter the kernel like the x86 does. --- Can you supply any facts to back up your FUD? Which 32-bit kernels couldn't implement a 64-bit interface The X86 code was approximately 12 lines of source code. Only 1 line of that was 'new' code (different from the 32 bit interface).
Implementing a 64 bit return interface simply simplifies the kernel code -- no need for special casing for 32-bit archs in the mainline code. 32 or 64 bits is an *architecture* difference that shouldn't be kludged for in the mainline code. Architectural differences are supposed to be hidden in the architecture specific code. It sure makes the code *more efficient* on 64 bit architectures and on the ia32 as well. All of the 32 bit archs support a 64 bit return value in their C compilers. I'd lay odds that it's more efficient on every one of them than allocating a buffer, passing in a pointer and doing an indirect store.
Why are you supporting special cases and complexity in the base line kernel code when its not necessary?
-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:09 EST