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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 B3B37C2D0BF for ; Wed, 18 Dec 2019 16:53:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5CBEF218AC for ; Wed, 18 Dec 2019 16:53:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="IQ/5SIJ2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5CBEF218AC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 17EFD8E0134; Wed, 18 Dec 2019 11:53:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 130288E00F5; Wed, 18 Dec 2019 11:53:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01E6F8E0134; Wed, 18 Dec 2019 11:53:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DD7628E00F5 for ; Wed, 18 Dec 2019 11:53:25 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id A31128249980 for ; Wed, 18 Dec 2019 16:53:25 +0000 (UTC) X-FDA: 76278857970.06.goose72_ba064f1b625 X-HE-Tag: goose72_ba064f1b625 X-Filterd-Recvd-Size: 6336 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Wed, 18 Dec 2019 16:53:24 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id l2so2922422lja.6 for ; Wed, 18 Dec 2019 08:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3qRY5XWsuCN6n8xU9fQoJH+pjwO3CHxgP4k/GmBdPYo=; b=IQ/5SIJ292ei03NolmBfEocYNplOmoBhNP+TWlRlx+4myoE2yY3tCOpuPqX84ODewr ZxIOOBR4eB7XLKzlxlNHA06k/cN6HUup8nG4oOWMpGflrWzw93Hd0PHehXWWyDZ6ZG3V w6hWLdp59SrCGRimV2hdbFAi3ES7UIYg62ve8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3qRY5XWsuCN6n8xU9fQoJH+pjwO3CHxgP4k/GmBdPYo=; b=PnJJoLB8KTqi7IWHeoO9CQmjdowHFlcG3Daa7xLYUSwh6Bxw9Zy1CNQdWB1pyY7luq ddZ3Yc4r6eLTiladt4plrOJ98jThN6FzEbKxDIuSFL+7rnLkYk4SYebK0gR1IqCixj0k grnMnNMO3kUxp+zxr/VKaRON8pzdyshX/xQka4R1MXMXRCEZx/iHughiXeBISifhvojz +uZsN8MerFRYwZMD9KAY4o3YjXnXlnEN9HFnAq4cf0S4lLn4glpJLklRPN65K1ftCfSf D0OIk4VSzWBG17WeUKogGQcdPGB81kDW0kbBY9a0JlT9UG9dkXWSBKOVWpnBx6v0H2Q0 Wb8Q== X-Gm-Message-State: APjAAAXRxLFhLyhL+LMAMDmlKp4SOrjJXdypCF5A9SeSOOqN94kKI1RM 1oqe8tp0e49UbJKdGMRuZADR/RKVhNk= X-Google-Smtp-Source: APXvYqxCxIyeZxb3X7d52k4yElhFGhhYtV2MpuMSJ36Hbg/M9DDweYWTNjzK/jp1PYMQQC7QSK/GJg== X-Received: by 2002:a2e:b5d5:: with SMTP id g21mr2534972ljn.89.1576688003508; Wed, 18 Dec 2019 08:53:23 -0800 (PST) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com. [209.85.208.180]) by smtp.gmail.com with ESMTPSA id g6sm1493699lja.10.2019.12.18.08.53.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Dec 2019 08:53:22 -0800 (PST) Received: by mail-lj1-f180.google.com with SMTP id a13so2911265ljm.10 for ; Wed, 18 Dec 2019 08:53:22 -0800 (PST) X-Received: by 2002:a2e:9041:: with SMTP id n1mr2508178ljg.133.1576688001995; Wed, 18 Dec 2019 08:53:21 -0800 (PST) MIME-Version: 1.0 References: <20191125204248.GA2485@ziepe.ca> <20191203024206.GC5795@mellanox.com> <20191205160324.GB5819@redhat.com> <20191211225703.GE3434@mellanox.com> <20191213101916.GD624164@phenom.ffwll.local> <20191218145913.GO16762@mellanox.com> In-Reply-To: <20191218145913.GO16762@mellanox.com> From: Linus Torvalds Date: Wed, 18 Dec 2019 08:53:05 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] Please pull hmm changes To: Jason Gunthorpe Cc: Jerome Glisse , Ralph Campbell , David Airlie , "Kuehling, Felix" , Dan Williams , "dri-devel@lists.freedesktop.org" , "linux-mm@kvack.org" , "amd-gfx@lists.freedesktop.org" , "Deucher, Alexander" , Andrew Morton , Christoph Hellwig , "linux-rdma@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Dec 18, 2019 at 6:59 AM Jason Gunthorpe wrote: > > Do you think calling it 'mmn_subscriptions' is clear? Why do you want that "mmn"? Guys, the "mmn" part is clear from the _context_. The function name is When the function name is something like "mmu_interval_read_begin()", and the filename is "mm/mmu_notifier.c", you do NOT NEED silly prefixes like "mmn" for local variables. They add NOTHING. And they make the code an illegible mess. Yes, global function names need to be unique, and if they aren't really core, they want some prefix that explains the context, because global functions are called from _outside_ the context that explains them. But if it's a "struct mmu_interval_notifier" pointer, and it's inside a file that is all about these pointers, it shouldn't be called "mmn_xyz". That's not a name. That's line noise. So call it a "notifier". Maybe even an "interval_notifier" if you don't mind the typing. Name it by something _descriptive_. And if you want. And "subscriptions" is a lovely name. What does the "mmn" buy you? Just to clarify: the names I really hated were the local variable names (and the argument names) that were all entirely within the context of mm/mmu_notifier.c. Calling something "mmn_mm" is a random jumble of letters that looks more like you're humming than you're speaking. Don't mumble. Speak _clearly_. The other side of "short names" is that some non-local conventions exist because they are _so_ global. So if it's just a mm pointer, call it "mm". We do have some very core concepts in the kernel that permeate _everything_, and those core things we tend to have very short names for. So whenever you're working with VM code, you'll see lots of small names like "mm", "vma", "pte" etc. They aren't exactly clear, but they are _globally_ something you read and learn when you work on the Linux VM code. That's very diofferent from "mmn" - the "mmn" thing isn't some global shorthand, it is just a local abomination. So "notifier_mm" makes sense - it's the mm for a notifier. But "mmn_notifier" does not, because "mmn" only makes sense in a local context, and in that local context it's not any new information at all. See the difference? Two shorthands, but one makes sense and adds information, while the other is just unnecessary and pointless and doesn't add anything at all. Linus