From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit
Date: Mon, 21 Jan 2013 02:30:11 +0000 [thread overview]
Message-ID: <20130121023010.GR4939@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFwG2j_+2pjUJuZqT1yk0xDEyeFMgCxHmxAzfGXHO5qCXQ@mail.gmail.com>
On Sun, Jan 20, 2013 at 05:40:28PM -0800, Linus Torvalds wrote:
> On Sun, Jan 20, 2013 at 5:22 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Anyway, that's a separate story - semctl(2) is going to be ugly, no matter
> > what we do, but the rest of those guys doesn't have to. How about the
> > following (completely untested):
>
> Hmm. Looks like the RightThing(tm) to me.
>
> The thing that stands out that I question the value of that
> HAVE_SYSCALL_WRAPPERS thing. Is there any reason we don't just make
> all architectures use it? What's the downside? I'm not sure I see the
> point of the non-wrapper version.
Neither do I, to be honest. It might be saving us a few cycles on
some architectures, but I'd like to see examples of that. amd64
doesn't seem to be one, at least...
FWIW, there's another bit of ugliness around that area - all these
#define __SC_BLAH3, etc., all of the same form. This stuff begs for
something like
#define __MAP1(m,t,a) m(t,a)
#define __MAP2(m,t,a,...) m(t,a) __MAP1(m,__VA_ARGS__)
#define __MAP3(m,t,a,...) m(t,a) __MAP2(m,__VA_ARGS__)
#define __MAP4(m,t,a,...) m(t,a) __MAP3(m,__VA_ARGS__)
#define __MAP5(m,t,a,...) m(t,a) __MAP4(m,__VA_ARGS__)
#define __MAP6(m,t,a,...) m(t,a) __MAP5(m,__VA_ARGS__)
#define __MAP(n,...) __MAP##n(__VA_ARGS__)
with __MAP(x,__SC_DECL,__VA_ARGS__) instead of __SC_DECL##x(__VA_ARGS__)
etc. in users...
next prev parent reply other threads:[~2013-01-21 2:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-14 9:42 Issues with "x86, um: switch to generic fork/vfork/clone" commit Nicolas Dichtel
2013-01-19 6:38 ` Al Viro
2013-01-20 3:12 ` Al Viro
2013-01-20 20:53 ` Linus Torvalds
2013-01-20 21:28 ` Al Viro
2013-01-21 1:22 ` Al Viro
2013-01-21 1:40 ` Linus Torvalds
2013-01-21 2:30 ` Al Viro [this message]
2013-01-21 2:39 ` Linus Torvalds
2013-01-21 6:02 ` Al Viro
2013-01-21 22:55 ` [RFC] making HAVE_SYSCALL_WRAPPERS universal (Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit) Al Viro
2013-01-22 12:47 ` James Hogan
2013-01-22 12:47 ` James Hogan
2013-01-22 14:23 ` Al Viro
2013-01-22 13:16 ` Arnd Bergmann
2013-01-22 15:33 ` Arnd Bergmann
2013-01-21 9:00 ` Issues with "x86, um: switch to generic fork/vfork/clone" commit Nicolas Dichtel
-- strict thread matches above, loose matches on Subject: below --
2012-11-10 4:36 Michel Lespinasse
2012-11-10 4:51 ` Al Viro
2012-11-10 4:57 ` Michel Lespinasse
2012-11-10 5:33 ` Al Viro
2012-11-10 5:47 ` Michel Lespinasse
2012-11-10 7:33 ` Al Viro
2012-11-10 8:08 ` Michel Lespinasse
2012-11-10 18:59 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130121023010.GR4939@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.