From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LoOpM-0007ls-Br for qemu-devel@nongnu.org; Mon, 30 Mar 2009 17:15:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LoOpL-0007kh-GF for qemu-devel@nongnu.org; Mon, 30 Mar 2009 17:15:27 -0400 Received: from [199.232.76.173] (port=34903 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LoOpL-0007kS-AV for qemu-devel@nongnu.org; Mon, 30 Mar 2009 17:15:27 -0400 Received: from naru.obs2.net ([84.20.150.76]:45265 helo=narury.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LoOpK-0008T0-Qg for qemu-devel@nongnu.org; Mon, 30 Mar 2009 17:15:27 -0400 Received: from kos.to (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by narury.org (Postfix) with ESMTP id 584E33274058 for ; Tue, 31 Mar 2009 00:15:23 +0300 (EEST) Date: Tue, 31 Mar 2009 00:15:23 +0300 From: Riku Voipio Subject: Re: [Qemu-devel] [PATCH] linux-user: fix problems with inotify syscalls Message-ID: <20090330211523.GA3633@kos.to> References: <1238273386-7652-1-git-send-email-froydnj@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1238273386-7652-1-git-send-email-froydnj@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Sat, Mar 28, 2009 at 01:49:46PM -0700, Nathan Froyd wrote: > The sys_inotify* calls are defined if the target supports them and the > host supports the necessary syscalls. But the syscalls are handled if > the target supports them. This situation leads to compilation failures > when the host doesn't support the necessary syscalls, as the linker will > complain about undefined functions. Looks ok to me, this is how the *at syscalls are #ifdeffed as well. Acked-By: Riku Voipio > Fix this state of affairs by making the handling conditions the same as > the call definition conditions. > Signed-off-by: Nathan Froyd > --- > linux-user/syscall.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/linux-user/syscall.c b/linux-user/syscall.c > index 226ee6c..8608171 100644 > --- a/linux-user/syscall.c > +++ b/linux-user/syscall.c > @@ -6109,19 +6109,19 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1, > ret = do_futex(arg1, arg2, arg3, arg4, arg5, arg6); > break; > #endif > -#ifdef TARGET_NR_inotify_init > +#if defined(TARGET_NR_inotify_init) && defined(__NR_inotify_init) > case TARGET_NR_inotify_init: > ret = get_errno(sys_inotify_init()); > break; > #endif > -#ifdef TARGET_NR_inotify_add_watch > +#if defined(TARGET_NR_inotify_add_watch) && defined(__NR_inotify_add_watch) > case TARGET_NR_inotify_add_watch: > p = lock_user_string(arg2); > ret = get_errno(sys_inotify_add_watch(arg1, path(p), arg3)); > unlock_user(p, arg2, 0); > break; > #endif > -#ifdef TARGET_NR_inotify_rm_watch > +#if defined(TARGET_NR_inotify_rm_watch) && defined(__NR_inotify_rm_watch) > case TARGET_NR_inotify_rm_watch: > ret = get_errno(sys_inotify_rm_watch(arg1, arg2)); > break; > -- > 1.6.0.5 > > -- "rm -rf" only sounds scary if you don't have backups