Re: [PATCH] (for 2.3.99pre6) audit_ids system calls

From: Linda Walsh (
Date: Mon May 01 2000 - 15:41:37 EST

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?


-- Linda A Walsh | Trust Technology, Core Linux, SGI | Voice: (650) 933-5338

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:09 EST