On Tue, Jan 22, 2019 at 10:26:56AM +0100, Arnd Bergmann wrote: > On Mon, Jan 21, 2019 at 11:48 PM Christian Brauner <christian@xxxxxxxxxx> wrote: > > > > On Mon, Jan 21, 2019 at 03:44:17PM -0700, Jens Axboe wrote: > > > On 1/21/19 1:23 PM, Christian Brauner wrote: > > > > On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote: > > > >> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner <christian@xxxxxxxxxx> wrote: > > > >>> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote: > > > >>>> On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > > > >>> > > > >>> I plan on sending the pidfd branch with the new pidfd_send_signal() > > > >>> syscall for the 5.1 window. Should we somehow coordinate so that our > > > >>> branches don't conflict? Any suggestions? > > > >> > > > >> A conflict can't be avoided, but if you pick system call number 427 > > > >> for pidfd_send_signal, and Jens picks numbers 424 through 426 for > > > > > > > > That sounds good to me. Since it's only one syscall for the pidfd branch > > > > is there anything that speaks against me using 424? Given that the other > > > > patchset has 4 new syscalls. :) > > > > Jens, any objections? > > > > > > I'm fine with either one, I'll have to renumber in any case. But it's 3 > > > new syscalls (424, 425, 426), not 4. > > > > > > Arnd, what's the best way to make this switch now, in my tree? Would be > > > > Yeah, I'd like to know that as well. > > > > > great if I didn't have to change it again once I make the change. > > I'd suggest that you each just take the numbers we talked about and > add them in your respective git trees, at the end of the current tables. Great! Will do that today before Stephen does a new merge for -next. > > Stephen and Linus can then do a trivial add/add merge between the > three trees that does not involve changing any of the lines besides > keeping them in the right order. The result should then be > > == arch/x86/entry/syscalls/syscall_32.tbl > 422 i386 futex_time64 sys_futex __ia32_sys_futex > 423 i386 sched_rr_get_interval_time64 > sys_sched_rr_get_interval __ia32_sys_sched_rr_get_interval > 424 i386 pidfd_send_signal sys_pidfd_send_signal > __ia32_sys_pidfd_send_signal > 425 i386 io_uring_setup sys_io_uring_setup > __ia32_compat_sys_io_uring_setup > 426 i386 io_uring_enter sys_io_uring_enter > __ia32_sys_io_uring_enter > 427 i386 io_uring_register sys_io_uring_register > __ia32_sys_io_uring_register > > == arch/x86/entry/syscalls/syscall_64.tbl > ... > 334 common rseq __x64_sys_rseq > # don't use numbers 387 through 423, add new calls after the last > # 'common' entry > 424 common pidfd_send_signal __x64_sys_pidfd_send_signal > 425 common io_uring_setup __x64_sys_io_uring_setup > 426 common io_uring_enter __x64_sys_io_uring_enter > 427 common io_uring_register __x64_sys_io_uring_register > # > # x32-specific system call numbers start at 512 to avoid cache impact > # for native 64-bit operation. The __x32_compat_sys stubs are created > # on-the-fly for compat_sys_*() compatibility system calls if X86_X32 > # is defined. > # > 512 x32 rt_sigaction __x32_compat_sys_rt_sigaction > ... > > My hope is that in the future, any new system call will get added to > all 16 syscall.tbl files at once, but let's maybe not do this for 5.1 > yet, since that only causes more conflicts. I can simply follow up > with a patch to add pidfd_send_signal and io_uring_* everywhere > during the merge window. Sounds good to me. Thanks Arnd! Christian
