lkml.org 
[lkml]   [2018]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Can we drop upstream Linux x32 support?
    Andy Lutomirski dixit:

    >What happens if someone adds a struct like:
    >
    >struct nasty_on_x32 {
    > __kernel_long_t a;
    > void * __user b;
    >};
    >
    >On x86_64, that's two 8-byte fields. On x86_32, it's two four-byte
    >fields. On x32, it's an 8-byte field and a 4-byte field. Now what?

    Yes, that’s indeed ugly. I understand. But don’t we already have
    this problem with architectures which support multiple ABIs at the
    same time? An amd64 kernel with i386 userspace comes to mind, or
    the multiple MIPS ABIs.

    >I'm sure we could have some magic gcc plugin or other nifty tool that
    >gives us:
    >
    >copy_from_user(struct struct_name, kernel_ptr, user_ptr);

    Something like that might be useful. Generate call stubs, which
    then call the syscall implementation with the actual user-space
    struct contents as arguments. Hm, that might be too generic to
    be useful. Generate macros that can read from or write specific
    structures to userspace?

    I think something like this could solve other more general problems
    as well, so it might be “nice to have anyway”. Of course it’s work,
    and I’m not involved enough in Linux kernel programming to be able
    to usefully help with it (doing too much elsewhere already).

    >actually do this work. Instead we get ad hoc fixes for each syscall,
    >along the lines of preadv64v2(), which get done when somebody notices

    Yes, that’s absolutely ugly and ridiculous and all kinds of bad.

    On the other hand, from my current experience, someone (Arnd?) noticed
    all the currently existing baddies for x32 already and fixed them.

    New syscalls are indeed an issue, but perhaps something generating
    copyinout stubs could help. This might allow other architectures
    that could do with a new ABI but have until now feared the overhead
    as well. (IIRC, m68k could do with a new ABI that reserves a register
    for TLS, but Geert would know. At the same time, time_t and off_t could
    be bumped to 64 bit. Something like that. If changing sizes of types
    shared between kernel and user spaces is not something feared…)

    Thanks for considering,
    //mirabilos
    --
    „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
    mksh auf jedem System zu installieren.“
    -- XTaran auf der OpenRheinRuhr, ganz begeistert
    (EN: “[…]uhr.gz is a reason to install mksh on every system.”)

    \
     
     \ /
      Last update: 2018-12-12 00:40    [W:4.264 / U:25.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site