lkml.org 
[lkml]   [2011]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: RFD: x32 ABI system call numbers
    From
    On Sun, Sep 4, 2011 at 2:13 PM, Arnd Bergmann <arnd@arndb.de> wrote:
    > On Sunday 04 September 2011 12:31:25 H.J. Lu wrote:
    >> On Sun, Sep 4, 2011 at 12:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
    >> >> #define __NR_x32_ioctl
    >> >
    >> > What do you plan to do for ioctl? Does this mean you want to
    >> > have a third file_operations pointer besides ioctl and compat_ioctl?
    >> > I would hope that you manage this by using different ioctl command
    >> > numbers in the few cases where the x32 version has to differ from
    >> > the x86-32 data structure.
    >>
    >> This requires some kernel changes since x32 has 32bit pointers and 64bit
    >> time_t/timespec/timeval.   We can't use straight x86-32 nor x86-64.
    >
    > I understand that it's not easy, but how do you want to get there?
    > There is no central implementation of ioctl, it's all in the device drivers!
    >
    > My point was that the part that you do control is the ABI for x32, so
    > you can change the driver's header files to do things like
    >
    > #ifndef __x32__
    > struct foo_ioctl_data {
    >        time_t  time;
    >        long            something_else;
    >        __u64           something_big;
    > };
    > #else
    > struct foo_ioctl_data {
    >        time_t  time;
    >        long long       something_else;
    >        __u64           something_big;
    > };
    > #endif
    >
    > #define FOO_IOCTL_BAR _IOR('f', 0, struct foo_ioctl_data)
    >
    > #ifdef __KERNEL__
    > struct compat_foo_ioctl_data {
    >        compat_time_t   time;
    >        compat_long_t   something_else;
    >        compat_u64              something_big;
    > };
    > #define FOO_IOCTL32_BAR _IOR('f', 0, struct compat_foo_ioctl_data)
    >
    > static long foo_compat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
    > {
    >        void __user *uptr = compat_ptr(arg)
    >
    >        switch (cmd) {
    >                case FOO_IOCTL32_BAR: /* regular compat case */
    >                        return foo_compat_ioctl_bar(filp, uptr);
    >                case FOO_IOCTL_BAR: /* x32 passing native struct */
    >                        return foo_ioctl_bar(filp, uptr);
    >        }
    >        return -ENOIOCTLCMD;
    > }
    >
    > This way, the same compat_ioctl function can easily support both x86-32 and
    > x32. In fact, many compat_ioctl handlers already contain two code paths for the
    > compat_u64 case, where they fall back on the native handler for anything but x86.

    This is one way to deal with itoctl. I will leave it to Peter.

    >> >> #define __NR_x32_recvfrom
    >> >> #define __NR_x32_sendmsg
    >> >> #define __NR_x32_recvmsg
    >> >> #define __NR_x32_recvmmsg
    >> >> #define __NR_x32_sendmmsg
    >> >
    >> > These today use the MSG_CMSG_COMPAT flag to distinguish native and compat
    >> > calls. Do you plan to have another flag here to handle cmsg time values?
    >>
    >> I am using x86-32 calls for them.
    >>
    >> > What about things like mq_{get,set}attr, quotactl and semtimedop?
    >> >
    >>
    >> I am using 64bit system calls for x32.
    >
    > But isn't that broken? These all pass u64 or time_t values at some point.
    >

    time_t isn't a problem since time_t/timeval/timespec are identical for
    x32 and x86-64. As for u64, I added NATIVE_LONG_TYPE, which is
    defined as long long for x32, and use it instead of long in types for
    64bit system calls.


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

    \
     
     \ /
      Last update: 2011-09-04 23:29    [W:2.917 / U:0.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site