[lkml]   [2011]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFD: x32 ABI system call numbers
    On Sun, Sep 4, 2011 at 8:17 AM, Arnd Bergmann <> wrote:
    > On Saturday 03 September 2011 10:27:42 H. Peter Anvin wrote:
    >> On 09/03/2011 10:16 AM, wrote:
    >> >>
    >> >> The complexity of changing that would be enormous.
    >> >
    >> > Oh, I know changing the x86-32 ABI is impossible - I meant changing the
    >> > decision to emulate that ABI (as opposed to emulating the x86-64 ABI, or a
    >> > variant thereof, or something else).  Or are we already commited to that
    >> > route, even if we're still trying to figure out what syscalls to include?
    >> >
    >> About ioctl in particular, the ABI has dependencies into almost every
    >> single driver in the Linux kernel.  It is hard-coded in the kernel that
    >> there are two paths -- native and compat.  Since pointers are going to
    >> be 4 bytes, it means we have to use the compat path.
    >> We may be able to cheat a little bit since we encode the argument sizes
    >> in the ioctl numbers; this solves the case of PPGETTIME/PPSETTIME for
    >> example (in fact, this ioctl looks currently broken in compat mode!)
    >> However, at some point the sheer number of data types that can be
    >> consumed by ioctl is a real concern, so changing the ones we really care
    >> about -- like timespec/timeval -- while leaving the rest intact so we
    >> can use the compat path as a general rule would be highly useful.
    > The ppdev ioctls are indeed missing in user space, and they are
    > an example for a different problem than the one I meant.
    > We really have a number of different cases that we will have to
    > deal with in different ways:
    > * different layout and ioctl code due to padding on x86-32,
    >  x32 is compatible:
    > * different layout due to padding on x86-32, but same ioctl code:
    > * uses time_t, different ioctl code:
    >  VIDIOC_QBUF32
    > * uses time_t, same ioctl code:
    > * Different alignment, three different ioctl numbers:
    >  FS_IOC_RESVSP_32
    >  FS_IOC_RESVSP64_32
    > * manually checks if compat_task:
    >  input/evdev
    > * Very complex, no easy solution:
    >  XFS_IOC_*
    > * Only needed for x86-32, not for x32:
    >  sys_quotactl
    > * Data structures embed time values, not an ioctl
    >  sys_sendmsg (cmsg)
    >  sys_recvmsg (cmsg)
    >  sys_mq_*
    >  sys_semtimedop
    > For a lot of these cases, the best option is to change the
    > kernel headers to use new definitions on x32 before someone
    > tries to ship a distro, especially when the ioctl command code
    > is fixed. In case of the XFS ioctls, I think the only sane
    > way is define the x32 ABI to match the 64 bit ABI completely,
    > while for RAW_GETBIND and VIDEO_GET_EVENT it's probably enough
    > to make x32 match x86-32.
    >        Arnd

    I need to use the following compat system calls for x32 due to
    pointers or longs in struct passed to system calls.

    #define __NR_x32_rt_sigaction
    #define __NR_x32_rt_sigprocmask
    #define __NR_x32_rt_sigreturn
    #define __NR_x32_ioctl
    #define __NR_x32_readv
    #define __NR_x32_writev
    #define __NR_x32_recvfrom
    #define __NR_x32_sendmsg
    #define __NR_x32_recvmsg
    #define __NR_x32_execve
    #define __NR_x32_times
    #define __NR_x32_rt_sigpending
    #define __NR_x32_rt_sigtimedwait
    #define __NR_x32_rt_sigqueueinfo
    #define __NR_x32_sigaltstack
    #define __NR_x32__sysctl
    #define __NR_x32_timer_create
    #define __NR_x32_mq_notify
    #define __NR_x32_kexec_load
    #define __NR_x32_waitid
    #define __NR_x32_set_robust_list
    #define __NR_x32_get_robust_list
    #define __NR_x32_vmsplice
    #define __NR_x32_move_pages
    #define __NR_x32_preadv
    #define __NR_x32_pwritev
    #define __NR_x32_rt_tgsigqueueinfo
    #define __NR_x32_recvmmsg
    #define __NR_x32_sendmmsg
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-09-04 20:43    [W:0.034 / U:31.668 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site