On Fri, 2011-11-11 at 17:09 +0100, Émeric Maschino wrote: > 2011/11/11 Ben Hutchings <b...@decadent.org.uk>: > >> --- a/arch/ia64/include/asm/unistd.h 2011-03-15 02:20:32.000000000 +0100 > >> +++ b/arch/ia64/include/asm/unistd.h 2011-11-10 21:27:31.000000000 +0100 > >> @@ -315,11 +315,12 @@ > >> #define __NR_fanotify_init 1323 > >> #define __NR_fanotify_mark 1324 > >> #define __NR_prlimit64 1325 > >> +#define __NR_accept4 1326 > >> > >> #ifdef __KERNEL__ > >> > >> > >> -#define NR_syscalls 302 /* length of syscall table */ > >> +#define NR_syscalls 303 /* length of syscall table */ > >> > >> /* > >> * The following defines stop scripts/checksyscalls.sh from complaining > >> about > >> > >> > >> --- a/arch/ia64/kernel/entry.S 2011-03-15 02:20:32.000000000 +0100 > >> +++ b/arch/ia64/kernel/entry.S 2011-11-10 21:32:03.000000000 +0100 > >> @@ -1771,6 +1771,7 @@ > >> data8 sys_fanotify_init > >> data8 sys_fanotify_mark > >> data8 sys_prlimit64 // 1325 > >> + data8 sys_accept4 > >> > >> .org sys_call_table + 8*NR_syscalls // guard against > >> failures to increase NR_syscalls > >> #endif /* __IA64_ASM_PARAVIRTUALIZED_NATIVE */ > >> > >> > > > > The above changes look reasonable; please send them to > > linux-i...@vger.kernel.org with a signed-off-by line as explained in > > Documentation/SubmittingPatches. > > OK, will do. > > I however imagine that these patches are to be created against current > linux-3.2-rc1 source tree, right?
Yes. > One thing that thus worries me is > that I won't be able to test the resulting kernel, since that the > initramfs-tools 0.99 issue prevents me from running kernel > 2.6.38. No it doesn't. The Debian packagaing of new kernel versions depends on new initramfs-tools, but the upstream code does not. > >> However, even with these patches applied, test_accept4 still report > >> that accept4() is not implemented :-(. > > > > Isn't that because it is using the installed header which doesn't define > > __NR_accept4? > > > >> What am I still missing? > > > > Don't know can you point to the version of test_accept4 that you are > > using? I only found the original version which is explicitly for x86 > > only. > > Sorry Ben, you were CC'ed too lately in the discussion! > > I was referring to the test_accept4.c file that I've modified and > attached in Message #25 > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647825#25). Here's > the direct link to get the file: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=test_accept4.c;att=1;bug=647825 That version just calls the libc implementation of accept4(), which won't work until libc is rebuilt. You need to define __NR_accept4 and call syscall(__NR_accept4, ...) in the test program instead. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong.
signature.asc
Description: This is a digitally signed message part
