Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200227132826.195669-1-brgerst@gmail.com> <20200227132826.195669-2-brgerst@gmail.com>
 <CALCETrWqmpChXCs0b-rO4X-yKKy0Afy3ioaK01ZmeiCvsN=3+Q@mail.gmail.com>
In-Reply-To: <CALCETrWqmpChXCs0b-rO4X-yKKy0Afy3ioaK01ZmeiCvsN=3+Q@mail.gmail.com>
From:   Brian Gerst <brgerst@gmail.com>
Date:   Fri, 28 Feb 2020 14:34:44 -0500
Message-ID: <CAMzpN2hwvAzMYrem7rN7nKs991qp_UwAtt5Nfw5RmVCm3abTuQ@mail.gmail.com>
Subject: Re: [PATCH v3 1/8] x86, syscalls: Refactor SYSCALL_DEFINEx macros
To:     Andy Lutomirski <luto@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@alien8.de>,
        "H . Peter Anvin" <hpa@zytor.com>,
        Dominik Brodowski <linux@dominikbrodowski.net>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Feb 28, 2020 at 1:33 PM Andy Lutomirski <luto@kernel.org> wrote:
>
> On Thu, Feb 27, 2020 at 5:28 AM Brian Gerst <brgerst@gmail.com> wrote:
> >
> > Pull the common code out from the SYSCALL_DEFINEx macros into a new
> > __SYS_STUBx macro.  Also conditionalize the X64 version in preparation for
> > enabling syscall wrappers on 32-bit native kernels.
> >
> > Signed-off-by: Brian Gerst <brgerst@gmail.com>
> > ---
>
>
>
> > -#define COMPAT_SYSCALL_DEFINEx(x, name, ...)                                   \
> > -       static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__));      \
> > -       static inline long __do_compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
> > -       __IA32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)                           \
> > -       __X32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)                            \
> > -       static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))       \
> > -       {                                                                       \
> > -               return __do_compat_sys##name(__MAP(x,__SC_DELOUSE,__VA_ARGS__));\
> > -       }                                                                       \
> > -       static inline long __do_compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
> > +#define COMPAT_SYSCALL_DEFINEx(x, name, ...)                           \
> > +       static long                                                     \
> > +       __se_compat_sys##name(__MAP(x, __SC_LONG, __VA_ARGS__));        \
> > +       static inline long                                              \
> > +       __do_compat_sys##name(__MAP(x, __SC_DECL, __VA_ARGS__));        \
> > +       __IA32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)                   \
> > +       __X32_COMPAT_SYS_STUBx(x, name, __VA_ARGS__)                    \
> > +       static long                                                     \
> > +       __se_compat_sys##name(__MAP(x, __SC_LONG, __VA_ARGS__))         \
> > +       {                                                               \
> > +               return __do_compat_sys##name(                           \
> > +                       __MAP(x, __SC_DELOUSE, __VA_ARGS__));           \
> > +       }                                                               \
> > +       static inline long                                              \
> > +       __do_compat_sys##name(__MAP(x, __SC_DECL, __VA_ARGS__))
> >
>
> This hunk looks like a pure anti-cleanup.  I much prefer slightly long
> lines over messy excessively multi-line macros.

Yeah, after several iterations this ended up back in it's original
form other than whitespace changes.  Personally I think the 80-column
hard limit is silly in this age of 4k widescreen monitors, and can
lead to some weird line breaks in certain cases, but that's still the
rule.

--
Brian Gerst