From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcUq8-0007H5-O7 for qemu-devel@nongnu.org; Mon, 30 Mar 2015 04:14:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcUq4-0005Pg-Pl for qemu-devel@nongnu.org; Mon, 30 Mar 2015 04:14:32 -0400 Received: from mail-wg0-x234.google.com ([2a00:1450:400c:c00::234]:33637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcUq4-0005PT-IM for qemu-devel@nongnu.org; Mon, 30 Mar 2015 04:14:28 -0400 Received: by wgbgs4 with SMTP id gs4so72994080wgb.0 for ; Mon, 30 Mar 2015 01:14:28 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <551905E0.6020103@redhat.com> Date: Mon, 30 Mar 2015 10:14:24 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1424883128-9841-1-git-send-email-dgilbert@redhat.com> <1424883128-9841-23-git-send-email-dgilbert@redhat.com> <20150313012346.GA11973@voom.redhat.com> <20150313104153.GB2486@work-vm> In-Reply-To: <20150313104153.GB2486@work-vm> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 22/45] postcopy: OS support test List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" , David Gibson Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, quintela@redhat.com, qemu-devel@nongnu.org, amit.shah@redhat.com, yanghy@cn.fujitsu.com On 13/03/2015 11:41, Dr. David Alan Gilbert wrote: >>> > > +#ifdef HOST_X86_64 >>> > > +#ifndef __NR_userfaultfd >>> > > +#define __NR_userfaultfd 323 >> > >> > Sholdn't this come from the kernel headers imported in the previous >> > patch? Rather than having an arch-specific hack. > The header, like the rest of the kernel headers, just provides > the constant and structure definitions for the call; the syscall numbers > come from arch specific headers. I guess in the final world I wouldn't > need this at all since it'll come from the system headers; but what's > the right way to put this in for new syscalls? > You would just require new _installed_ kernel headers. Then you can use linux/userfaultfd.h and syscall.h (the latter from glibc, includes asm/unistd.h to get syscall numbers). linux-headers/ is useful for APIs that do not require system calls, or for APIs that are extensible. However, if a system call is required (and mandatory) it's simpler to just use installed headers. Paolo