Re: RFD: x32 ABI system call numbers

[H. Peter Anvin]

On 08/26/2011 06:18 PM, Linus Torvalds wrote:
> On Fri, Aug 26, 2011 at 5:53 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>>
>> Unfortunately, there is actually a reason for the use of "unsigned long"
>> here -- it means that the combination of the time and the _nsec fields
>> matches struct timespec.  struct timespec/struct timeval is one of those
>> things that it would be really nice if we *could* change (it's not
>> inherently pointer-sized, and it really should be 64 bits), but struct
>> timespec and struct timeval are embedded in a a number of memory
>> structures, some of which have pointers; and they are used by ioctls.
> 
> But for "struct stat"? You can't depend on that anyway.

No, but since we have the conversion function in the kernel already it
seems we might as well use it.

> And I really do think that a new 32-bit ABI is *much* better off
> trying to be compatible with x86-64 (and avoiding things like 2038)
> than it is trying to be compatible with the old-style x86-32 binaries.
> I realize that it may be *easier* to be compatible with x86-32 and
> just add a few new system calls, but I think it's wrong.

It is wrong to more than a small degree, to be sure.  However, "easier"
here is the difference of working through every data structure used by
every ioctl in every driver in the kernel and figure out which ones have
pointers or pointer-sized items, when that is work that has already been
done once.  Admittedly that does come with some legacy, but it does not
appear to be a significant extra cost.

Y2038 is certainly the single biggest issue here, and I fully admit to
not having a good answer on that one.  Note that applies to every single
32-bit ABI in the Linux kernel, including asm-generic which is used by
all brand new architectures.

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