Re: RFD: x32 ABI system call numbers

[Arnd Bergmann <arnd@arndb.de>]

On Monday 29 August 2011, H. Peter Anvin wrote:
> On 08/29/2011 08:04 AM, Arnd Bergmann wrote:
> > 
> > Right. The asm-generic/unistd.h interface doesn't provide them either
> > for new architectures and expects libc to emulate them for any user
> > application whose developers can't be bothered to fix their code.
> > 
> > I think I've also commented in the past that I think x32 should use
> > the same set of syscalls asm asm-generic, even if it's more convenient
> > to use a different ordering.
> > 
> 
> It definitely is not convenient to use asm-generic for a whole lot of
> reasons, which basically comes down to leveraging the existing x86-64
> system calls plus leveraging the i386-on-x86-64 compat layer as much as
> possible.

Yes, but that's not what I meant. My point was that any new architecture
should have only the set of 269 syscalls that asm-generic has, i.e. 
no none of the syscalls that have been replaced for any number of
reasons (large files, *at, uid32, pselect).

I do agree that you should keep using the x86 data structures unless
there is a good reason to do otherwise, and I agree that you should
keep using the syscall numbers for the calls that remain, but I would
just leave out from the ABI the calls that are no longer necessary.

> I talked to H.J. this morning and we're certainly dropping the 32-bit
> filesystem calls.  I'm going to audit which paths have both time_t
> (including struct timespec/timeval) and pointers; that is hopefully a
> matter of legwork.  This will mean introducing new ioctls, but it's not
> clear how many.
> 
> The end result is going to be bigger than the current patchset (which is
> +2197 -510, and most of which is just the system call tables themselves;
> the balance is only +690 -105), but it is definitely a better ABI.

Ok.

I'm wondering about the time_t changes: given that we are still adding
new 32 bit architectures, should we change the asm-generic API as well
to use 64 bit time_t by default (with fallbacks for the existing ones)?

If you are adding support for these in x32 already, we could use the
same code for regular 32 bit architectures.

	Arnd