On Fri, 2011-11-11 at 00:05 +0100, Émeric Maschino wrote: [...] > > I think we need this, which applies cleanly to the current kernel > > version in squeeze: > > > > commit 9ab87644393d789b950ba984fa360f45c4df02e5 > > Author: Arnd Bergmann <arnd@arndb.de> > > Date: Thu Dec 10 22:10:31 2009 +0100 > > > > asm-generic: add sys_accept4 to unistd.h > > > > Can someone test that the attached patch is sufficient to make the new > > udev work on ia64? (See the instructions at > > <kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>.) > > Since current kernel 3.0.0+39 in Wheezy cannot be installed due to the > initramfs-tools 0.99 issue, I tried to apply the patch to "last > working in Wheezy" 2.6.38+34 kernel. Patch was rejected as > include/asm-generic/unistd.h in 2.6.38+34 already has __NR_accept4 > defined to 242. Sorry, I assumed that ia64 must have accept4() in the current upstream version (3.1) and we only needed to worry about squeeze. So I wrongly thought that patch must have been the change that added it to ia64. > I know nothing about kernel development, And nothing about ia64 > architecture. However, looking at various kernel commits in order to > understand how accept4 support was added for other architectures, and > also looking at how accept() is currently defined for ia64, I ended up > modifying the following files (patches against Wheezy 2.6.38+34 > kernel, in attached): > > --- 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-ia64@vger.kernel.org with a signed-off-by line as explained in Documentation/SubmittingPatches. > --- a/arch/ia64/kernel/fsys.S 2011-03-15 02:20:32.000000000 +0100 > +++ b/arch/ia64/kernel/fsys.S 2011-11-10 21:34:53.000000000 +0100 > @@ -1042,7 +1042,29 @@ > data8 0 // tee > data8 0 // vmsplice > data8 0 > - data8 fsys_getcpu // getcpu // 1304 > + data8 fsys_getcpu // getcpu > + data8 0 // 1305 > + data8 0 > + data8 0 > + data8 0 > + data8 0 > + data8 0 // 1310 > + data8 0 > + data8 0 > + data8 0 > + data8 0 > + data8 0 // 1315 > + data8 0 > + data8 0 > + data8 0 > + data8 0 > + data8 0 // 1320 > + data8 0 > + data8 0 > + data8 0 > + data8 0 > + data8 0 // 1325 > + data8 0 // accept4 // 1326 > > // fill in zeros for the remaining entries > .zero: > > For fsys.S, I don't know if adding "data8 0" lines like I did in order > to match accept4() 1326 define with unistd.h and entry.S is required > or not. If yes, well, table hasn't been updated from quite some time > then! The comment means that the .space directive will add the necessary trailing zero entries automatically. So you don't need to edit this file. > 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. Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong.
Attachment:
signature.asc
Description: This is a digitally signed message part