|| ||Linus Torvalds <torvalds-AT-linux-foundation.org> |
|| ||"H. Peter Anvin" <hpa-AT-zytor.com> |
|| ||Re: RFD: x32 ABI system call numbers |
|| ||Fri, 26 Aug 2011 18:42:35 -0700|
|| ||LKML <linux-kernel-AT-vger.kernel.org>,
"H.J. Lu" <hjl.tools-AT-gmail.com>, Ingo Molnar <mingo-AT-elte.hu>,
Thomas Gleixner <tglx-AT-linutronix.de>|
|| ||Article, Thread
On Fri, Aug 26, 2011 at 6:12 PM, H. Peter Anvin <firstname.lastname@example.org> wrote:
> For reference, this is the current list (again, unaudited!) of unshared
> system calls. Only the ones with *x32* in the the entry point name have
> any new code in the kernel at all.
So a *lot* of these make me extremely unhappy.
> # x32 system calls start at 512 to avoid cache impact for native 32 bit
> 512 x32 open compat_sys_open
The only difference between open and compat_sys_open() is that the
latter doesn't set O_LARGEFILE, no?
That seems *extremely* wrong. Darn it, there is no reason we should
ever allow the old LARGEFILE crap in a new model. So why would we ever
want to that compat_open()?
> 513 x32 stat compat_sys_newstat
> 514 x32 fstat compat_sys_newfstat
> 515 x32 lstat compat_sys_newlstat
So these I'm unhappy with because I really think we should just use
the 64-bit stat format, instead of dicking around with the legacy
The native x86-64 stat is *better* than the crazy i386 formats, for
chissake! The i386 "newstat" has those crazy padding fields. They make
> 516 x32 rt_sigaction sys32_rt_sigaction
> 517 x32 rt_sigprocmask sys32_rt_sigprocmask
> 518 x32 rt_sigreturn stub_x32_rt_sigreturn
So these may be valid. I don't know what your stub_x32_rt_sigreturn
is, but I hope it still restores the full 64-bit registers? Even in
ULP64, I assume we still use 64-bit registers for "long long" etc?
> 519 x32 ioctl compat_sys_ioctl
> 520 x32 readv compat_sys_readv
> 521 x32 writev compat_sys_writev
Ok, these are the ones I expect. They are all about structures with
pointers in user space.
> 522 x32 select compat_sys_select
But this one I really suspect we'd be better off just having 64-bit
timeval, obviating the need for the compat system call.
time_t really *should* be 64-bit, the same way "off_t" should be. If
it's not, there's something wrong.
> 523 x32 shmat compat_sys_x32_shmat
> 524 x32 shmctl compat_sys_shmctl
I assume this is due to the same "return shm segment in low 4GB" thing.
I do think it would be better to have a "SHM_4G" flag that gets set by
user space, but I guess that's ok.
> 525 x32 nanosleep compat_sys_nanosleep
> 526 x32 getitimer compat_sys_getitimer
> 527 x32 setitimer compat_sys_setitimer
Again, these would be better off with a 64-bit time_t. Seriously.
> 528 x32 recvfrom compat_sys_recvfrom
> 529 x32 sendmsg compat_sys_sendmsg
> 530 x32 recvmsg compat_sys_recvmsg
Ok, pointers in user land.
> 531 x32 setsockopt compat_sys_setsockopt
> 532 x32 getsockopt compat_sys_getsockopt
Grr. I guess these fall under the same heading.
> 533 x32 execve stub_x32_execve
> 534 x32 wait4 compat_sys_wait4
Why is this? "rusage"? Can't we just make that 64-bit?
> 535 x32 semctl compat_sys_x32_semctl
> 536 x32 msgsnd compat_sys_x32_msgsnd
> 537 x32 msgrcv compat_sys_x32_msgrcv
> 538 x32 msgctl compat_sys_msgctl
> 539 x32 fcntl compat_sys_fcntl64
> 540 x32 getdents compat_sys_getdents
.. but why this? Isn't 'linux_dirent64' good enough?
> 541 x32 gettimeofday compat_sys_gettimeofday
> 542 x32 getrlimit compat_sys_getrlimit
> 543 x32 getrusage compat_sys_getrusage
Looks like another "should just be 64-bit"
> 544 x32 sysinfo compat_sys_sysinfo
> 545 x32 times compat_sys_times
64-bit time_t should fix this.
> 560 x32 nfsservctl compat_sys_nfsservctl
We've removed this one.
.. lots more. It really looks annoying to me. A lot of the remaining
ones should just be "int 0x80", they aren't performance critical. Why
do they have to have new system call entry points?
to post comments)