This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] <bits/syscall.h>: Use an arch-independent system call list on Linux

On Thu, 24 Aug 2017, Florian Weimer wrote:

> * Joseph Myers:
> > I do not object to bounding the SYS_* API exported by glibc to a set of 
> > system calls known to that glibc version.
> >
> > I do object to having a test we know will fail when someone builds glibc 
> > with a newer set of kernel headers than that version of glibc.  That is, I 
> > think the test should allow extra __NR_* if the kernel headers have a 
> > newer (major.minor) version number than the kernel version listed in 
> > syscall-names.list.  That way, the test is still effective in development 
> > as long as people update the kernel number when adding syscalls to the 
> > file or doing other new-kernel-version updates, without causing spurious 
> > failures for people building past release versions / branches of glibc.
> Hmm.  The way the patch currently works, a missing built-in system
> call name is actually a user-visible bug because they won't get the
> SYS_* macro they expect (based on the kernel headers).  This is why I
> made it a test failure.

I don't see it as a user-visible bug - I see it as a deliberate change of 
the SYS_* API from "what's in the kernel headers with which glibc was 
built" to "what syscalls the glibc source tree knows about that are also 
in the kernel headers with which glibc is used".

> If we don't want that, I need to resurrect the old magic list
> generation and use its results to augment the built-in list.  The test
> can remain as-is, but it will no longer fail.

I think a key benefit of the patch is that it gets rid of that magic list 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]