From: Al Viro <viro@ZenIV.linux.org.uk>
To: Shane Hathaway <shane@hathawaymix.org>
Cc: user-mode-linux-devel@lists.sourceforge.net,
Jeff Dike <jdike@addtoit.com>,
linux-kernel@vger.kernel.org, Rob Landley <rob@landley.net>,
Am?rico Wang <xiyou.wangcong@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Daolong Wang <ahlongxp@gmail.com>
Subject: Re: [uml-devel] [Patch] uml: fix a link error
Date: Tue, 27 Jan 2009 09:23:14 +0000 [thread overview]
Message-ID: <20090127092314.GZ28946@ZenIV.linux.org.uk> (raw)
In-Reply-To: <49753063.8040007@hathawaymix.org>
On Mon, Jan 19, 2009 at 07:01:07PM -0700, Shane Hathaway wrote:
> The problem is that the name "sigprocmask" is getting renamed to
> "kernel_sigprocmask" by a compiler directive in arch/um/Makefile, then
> that name gets mangled into "sys_kernel_sigprocmask" by the
> SYSCALL_DEFINE3(sigprocmask, ...) macro in kernel/signal.c.
>
> So, instead of the patch suggested earlier, I added the following line
> to arch/um/sys-i386/sys_call_table.S:
>
> #define sys_sigprocmask sys_kernel_sigprocmask
Interesting... Everything else aside, we have difference in e.g.
SYSCALL_DEFINE0 and SYSCALL_DEFINE3 behaviours: SYSCALL_DEFINE0(name)
will *not* do macro expansion in name and SYSCALL_DEFINE3(name, blah, ...)
will.
The reason is that we have name carried through extra layer of macros
in the latter case. Argument is *NOT* a subject to expansion when it
is used with ##; however, passing it to another macro will expand it
just fine.
Regardless of the kludge with -D used by uml, I'd say that we want consistency
here; keeping the original behaviour would also be nice.
How about
#define SYSCALL_DEFINE1(name,...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
etc.
with
#define SYSCALL_DEFINEx(x, name, ...) \
asmlinkage long sys##name(__SC_DECL##x(__VA_ARGS__))
?
That gives consistent behaviour in all cases and avoids the insane side
effects like this one.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Shane Hathaway <shane@hathawaymix.org>
Cc: Daolong Wang <ahlongxp@gmail.com>, Jeff Dike <jdike@addtoit.com>,
Rob Landley <rob@landley.net>,
user-mode-linux-devel@lists.sourceforge.net,
Andrew Morton <akpm@linux-foundation.org>,
Am?rico Wang <xiyou.wangcong@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [uml-devel] [Patch] uml: fix a link error
Date: Tue, 27 Jan 2009 09:23:14 +0000 [thread overview]
Message-ID: <20090127092314.GZ28946@ZenIV.linux.org.uk> (raw)
In-Reply-To: <49753063.8040007@hathawaymix.org>
On Mon, Jan 19, 2009 at 07:01:07PM -0700, Shane Hathaway wrote:
> The problem is that the name "sigprocmask" is getting renamed to
> "kernel_sigprocmask" by a compiler directive in arch/um/Makefile, then
> that name gets mangled into "sys_kernel_sigprocmask" by the
> SYSCALL_DEFINE3(sigprocmask, ...) macro in kernel/signal.c.
>
> So, instead of the patch suggested earlier, I added the following line
> to arch/um/sys-i386/sys_call_table.S:
>
> #define sys_sigprocmask sys_kernel_sigprocmask
Interesting... Everything else aside, we have difference in e.g.
SYSCALL_DEFINE0 and SYSCALL_DEFINE3 behaviours: SYSCALL_DEFINE0(name)
will *not* do macro expansion in name and SYSCALL_DEFINE3(name, blah, ...)
will.
The reason is that we have name carried through extra layer of macros
in the latter case. Argument is *NOT* a subject to expansion when it
is used with ##; however, passing it to another macro will expand it
just fine.
Regardless of the kludge with -D used by uml, I'd say that we want consistency
here; keeping the original behaviour would also be nice.
How about
#define SYSCALL_DEFINE1(name,...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
etc.
with
#define SYSCALL_DEFINEx(x, name, ...) \
asmlinkage long sys##name(__SC_DECL##x(__VA_ARGS__))
?
That gives consistent behaviour in all cases and avoids the insane side
effects like this one.
next prev parent reply other threads:[~2009-01-27 10:39 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-15 19:40 [uml-devel] [Patch] uml: fix a link error Américo Wang
2009-01-15 19:40 ` Américo Wang
2009-01-16 20:41 ` [uml-devel] " Andrew Morton
2009-01-16 20:41 ` Andrew Morton
2009-01-16 21:38 ` [uml-devel] " Jeff Dike
2009-01-16 21:38 ` Jeff Dike
2009-01-17 9:28 ` [uml-devel] " Rob Landley
2009-01-17 9:28 ` Rob Landley
2009-01-18 6:23 ` Daolong Wang
2009-01-18 6:23 ` Daolong Wang
2009-01-19 15:21 ` Jeff Dike
2009-01-19 15:21 ` Jeff Dike
2009-01-20 1:46 ` Daolong Wang
2009-01-20 1:46 ` Daolong Wang
2009-01-20 2:01 ` Shane Hathaway
2009-01-20 2:01 ` Shane Hathaway
2009-01-27 9:23 ` Al Viro [this message]
2009-01-27 9:23 ` Al Viro
2009-02-04 17:26 ` Geert Uytterhoeven
2009-02-04 17:26 ` Geert Uytterhoeven
2009-02-04 20:32 ` Geert Uytterhoeven
2009-02-04 20:32 ` Geert Uytterhoeven
2009-02-04 20:40 ` Greg KH
2009-02-04 20:40 ` Greg KH
2009-02-04 20:54 ` Geert Uytterhoeven
2009-02-04 20:54 ` Geert Uytterhoeven
2009-02-07 11:59 ` Heiko Carstens
2009-02-07 11:59 ` Heiko Carstens
2009-02-08 9:07 ` Américo Wang
2009-02-08 9:07 ` Américo Wang
2009-02-08 9:12 ` Américo Wang
2009-02-08 9:12 ` Américo Wang
2009-02-12 14:40 ` Geert Uytterhoeven
2009-02-12 14:40 ` Geert Uytterhoeven
2009-01-18 8:32 ` Américo Wang
2009-01-18 8:32 ` Américo Wang
2009-01-18 23:29 ` Rob Landley
2009-01-18 23:29 ` Rob Landley
2009-01-22 16:12 ` Américo Wang
2009-01-22 16:12 ` Américo Wang
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=20090127092314.GZ28946@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=ahlongxp@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rob@landley.net \
--cc=shane@hathawaymix.org \
--cc=user-mode-linux-devel@lists.sourceforge.net \
--cc=xiyou.wangcong@gmail.com \
/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.