Message-ID: <CAMe9rOqJoy=S4-=tZXrti7w_GtSqaTgX9i69FR92Tv6pPfSDRQ@mail.gmail.com>
Date:	Sun, 4 Sep 2011 11:40:39 -0700
From:	"H.J. Lu" <hjl.tools@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Valdis.Kletnieks@...edu,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Richard Kuo <rkuo@...eaurora.org>,
	Mark Salter <msalter@...hat.com>,
	Jonas Bonn <jonas@...thpole.se>,
	Tobias Klauser <tklauser@...tanz.ch>
Subject: Re: RFD: x32 ABI system call numbers

On Sun, Sep 4, 2011 at 8:17 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Saturday 03 September 2011 10:27:42 H. Peter Anvin wrote:
>> On 09/03/2011 10:16 AM, Valdis.Kletnieks@...edu 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:
>  DRM_IOCTL_RADEON_SETPARAM
>  DRM_IOCTL_UPDATE_DRAW32
>  EXT4_IOC32_GROUP_ADD
>
> * different layout due to padding on x86-32, but same ioctl code:
>  RAW_SETBIND
>  RAW_GETBIND
>
> * uses time_t, different ioctl code:
>  PPPIOCGIDLE32
>  VIDIOC_DQBUF32
>  VIDIOC_QBUF32
>  VIDIOC_QUERYBUF32
>  VIDIOC_DQEVENT32
>
> * uses time_t, same ioctl code:
>  VIDEO_GET_EVENT
>  LPSETTIMEOUT
>
> * 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.

-- 
H.J.
---
#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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists