On Fri, Mar 16, 2018 at 07:03:53PM +0000, Andy Lutomirski wrote: > On Fri, Mar 16, 2018 at 6:43 PM, Darren Hart <dvh...@infradead.org> wrote: > > On Thu, Mar 15, 2018 at 08:04:56PM +0100, Dominik Brodowski wrote: > >> sys_futex() is a wrapper to do_futex() which does not modify any > >> values here: > >> > >> - uaddr, val and val3 are kept the same > >> > >> - op is masked with FUTEX_CMD_MASK, but is always set to FUTEX_WAKE. > >> Therefore, val2 is always 0. > >> > >> - as utime is set to NULL, *timeout is NULL > >> > >> Cc: Thomas Gleixner <t...@linutronix.de> > >> Cc: Ingo Molnar <mi...@redhat.com> > >> Cc: Peter Zijlstra <pet...@infradead.org> > >> Cc: Darren Hart <dvh...@infradead.org> > >> Cc: Andrew Morton <a...@linux-foundation.org> > >> Signed-off-by: Dominik Brodowski <li...@dominikbrodowski.net> > > > > Hi Dominik, > > > > I'm missing the "why" part here. What is it you are trying to address? > > > > do_futex is not currently in use outside of the futex implementation, > > while sys_futex is. This decouples the interface from the > > implementation. While this is perhaps less critical within the > > kernel, I don't see a compelling reason to increase the coupling > > between the mm and futex implementations. > > > > Without a compelling WHY, Nack from me. > > > > We want to make some changes to the way that the syscall entry code > invokes syscalls, and these changes will make it impossible to call > sys_xyz() functions from the kernel. So we can make sys_futex() be a > trivial wrapper around a new ksys_futex(), or we can do a patch like > this.
I dug up the cover letter and got the motivation and withdraw my objection. I understand the motivation to put the motivation in the cover letter in a large series, but I think there should have been something indicating the need for this change in the individual patches, even just a single line like Andy's first sentence above. Thanks, -- Darren Hart VMware Open Source Technology Center
