[CRIU] [PATCH 3/3] crtools: no more linked with builtin syscall

[Andrew Vagin]

On Tue, Mar 15, 2016 at 11:24:50AM +0100, Laurent Dufour wrote:
> On 14/03/2016 23:56, Andrew Vagin wrote:
> > On Wed, Feb 03, 2016 at 05:13:48PM +0100, Laurent Dufour wrote:
> >> diff --git a/shmem.c b/shmem.c
> >> index b2900f4f875d..0f9da630ccc5 100644
> >> --- a/shmem.c
> >> +++ b/shmem.c
> >> @@ -216,7 +216,7 @@ int get_shmem_fd(int pid, VmaEntry *vi)
> >>  
> >>  	flags = MAP_SHARED;
> >>  	if (kdat.has_memfd) {
> >> -		f = sys_memfd_create("", 0);
> >> +		f = syscall(SYS_memfd_create, "", 0);
> > 
> > SYS_memfd_create is defined in glibc which is updated after the kernel.
> > 
> > Without this patch we could install a new kernel and start to use new
> > system calls.
> > 
> > Now we need to wait when these syscalls appear in glibc. We need to
> > find a way how to fix this issue.
> > 
> > * It is impossible to test new feature in linux-next kernels
> > * We back-port a required syscalls into the OpenVZ kernel (e.g.
> >   memfd_create), but we don't provide glibc for these kernels.
> > 
> > Can we generate a header file with system-call numbers?
> 
> 
> There is already a generated file containing all the needed system call
> SYS_* defines : "syscall-codes.h".
> 
> Unfortunately the way it is generated is forcing the definition of the
> SYS_* even if it is already defined by the C library's header files, so
> I can't be included as is.
> 
> I'm working on a patch changing the way this file is defined, I'll send
> it asap.

Great! Thank you.

> 
> Cheers,
> Laurent.
>