From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7CAFBC43461 for ; Fri, 4 Sep 2020 09:36:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 599F5205CB for ; Fri, 4 Sep 2020 09:36:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729628AbgIDJgg (ORCPT ); Fri, 4 Sep 2020 05:36:36 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:33927 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725812AbgIDJgf (ORCPT ); Fri, 4 Sep 2020 05:36:35 -0400 Received: from ip5f5af70b.dynamic.kabel-deutschland.de ([95.90.247.11] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kE890-0006Sg-0v; Fri, 04 Sep 2020 09:36:30 +0000 Date: Fri, 4 Sep 2020 11:36:27 +0200 From: Christian Brauner To: Minchan Kim Cc: Florian Weimer , Andrew Morton , LKML , linux-mm , linux-api@vger.kernel.org, oleksandr@redhat.com, Suren Baghdasaryan , Tim Murray , Sandeep Patil , Sonny Rao , Brian Geffon , Michal Hocko , Johannes Weiner , Shakeel Butt , John Dias , Joel Fernandes , Jann Horn , alexander.h.duyck@linux.intel.com, sj38.park@gmail.com, David Rientjes , Arjun Roy , Linus Torvalds , Vlastimil Babka , Christian Brauner , Daniel Colascione , Jens Axboe , Kirill Tkhai , SeongJae Park , linux-man@vger.kernel.org Subject: Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API Message-ID: <20200904093627.vj6t6q5spicfyonh@wittgenstein> References: <20200901000633.1920247-1-minchan@kernel.org> <20200901000633.1920247-4-minchan@kernel.org> <87blippc7p.fsf@mid.deneb.enyo.de> <20200903172618.GB1959033@google.com> <87pn72lq65.fsf@mid.deneb.enyo.de> <20200903175949.GC1959033@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200903175949.GC1959033@google.com> Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Thu, Sep 03, 2020 at 10:59:49AM -0700, Minchan Kim wrote: > On Thu, Sep 03, 2020 at 07:34:58PM +0200, Florian Weimer wrote: > > * Minchan Kim: > > > > > On Tue, Sep 01, 2020 at 08:46:02PM +0200, Florian Weimer wrote: > > >> * Minchan Kim: > > >> > > >> > ssize_t process_madvise(int pidfd, const struct iovec *iovec, > > >> > unsigned long vlen, int advice, unsigned int flags); > > >> > > >> size_t for vlen provides a clearer hint regarding the type of special > > >> treatment needed for ILP32 here (zero extension, not changing the type > > >> to long long). > > >> > > > > > > All existing system calls using iove in Linux uses unsigned long so > > > I want to be consistent with them unless process_madvise need something > > > speicial. > > > > Userspace uses int, following POSIX (where applicable). There is no > > consistency to be had here. > > Okay, I changed it with size_t. Maybe some context helps. We had the discussion about syscall conventions during LPC both in the KernelSummit and in the glibc toolchain session and one of wishlist conventions from libc was to always use size_t and not unsigned long for sizes. I know this has been a little frustrating having to change types and so on for the syscall quite a bit but I'm going to start drafting an updated version of our howto for adding syscalls now so things like this are more transparent going forward. I just hadn't gotten around to it right after Plumbers. Christian