From: Christian Brauner <christian@brauner•io>
To: Arnd Bergmann <arnd@arndb•de>
Cc: Jens Axboe <axboe@kernel•dk>,
Stephen Rothwell <sfr@canb•auug.org.au>,
Linux Next Mailing List <linux-next@vger•kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
linux-arch <linux-arch@vger•kernel.org>
Subject: Re: linux-next: manual merge of the pidfd tree with the y2038 tree
Date: Tue, 22 Jan 2019 10:31:47 +0100 [thread overview]
Message-ID: <20190122093146.kmckcgdbvo2e7v3c@brauner.io> (raw)
In-Reply-To: <CAK8P3a0ej9NcJM8wXNPbcGUyOUZYX+VLoDFdbenW3s3114oQZw@mail.gmail.com>
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@brauner•io> 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@brauner•io> 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@canb•auug.org.au> 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
next prev parent reply other threads:[~2019-01-22 9:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 3:39 linux-next: manual merge of the pidfd tree with the y2038 tree Stephen Rothwell
2019-01-21 17:16 ` Arnd Bergmann
2019-01-21 19:13 ` Christian Brauner
2019-01-21 20:15 ` Arnd Bergmann
2019-01-21 20:23 ` Christian Brauner
2019-01-21 22:44 ` Jens Axboe
2019-01-21 22:48 ` Christian Brauner
2019-01-22 9:26 ` Arnd Bergmann
2019-01-22 9:31 ` Christian Brauner [this message]
2019-01-22 10:30 ` Christian Brauner
2019-01-22 10:48 ` Arnd Bergmann
2019-01-22 10:57 ` Christian Brauner
2019-01-22 11:42 ` Arnd Bergmann
2019-01-22 11:46 ` Christian Brauner
2019-01-22 12:24 ` Christian Brauner
2019-01-22 13:44 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2019-01-22 3:10 Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190122093146.kmckcgdbvo2e7v3c@brauner.io \
--to=christian@brauner$(echo .)io \
--cc=arnd@arndb$(echo .)de \
--cc=axboe@kernel$(echo .)dk \
--cc=linux-arch@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=sfr@canb$(echo .)auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox