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.9 required=3.0 tests=DKIMWL_WL_HIGH,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 1B8F3C43603 for ; Wed, 18 Dec 2019 16:53:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E3676218AC for ; Wed, 18 Dec 2019 16:53:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576688008; bh=8wQs1XkJLWxaSqLQNyUTZjlo2s26d8DLzjXMN4uSzOg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=R3flCPHn4iDI5X42XACo2+p8/l0q709N1W2wYk55WuO4rGLIJUZfPoPbgLw5mUhZt s4KEAja6F78S4lCYrWUhi3I93JzU57E1kKTsnNddTKBv5Ic6wZKQiHoVlo4oSFS0kF wjJAhjdDz9/XlxHzTvcZsR6Q/I5IjUZU+ziGh7qs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727184AbfLRQx0 (ORCPT ); Wed, 18 Dec 2019 11:53:26 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:44459 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726955AbfLRQx0 (ORCPT ); Wed, 18 Dec 2019 11:53:26 -0500 Received: by mail-lj1-f195.google.com with SMTP id u71so2909975lje.11 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=Wdtta43/IZB2LnuLONyvR8UF4WTS5kTWHkIbEPNr8rMtyb8Lj5jMpisJlZkuNmEcs6 Ld92aWTLuGrft5MmH3ZY6YqHr4c1XH3NV7GDK+IiUCC5+CP6uE0vz0CH4Eq7GHpIv9In LGf8M5QfioCIqQAbZ/v+U3sQC5cHYE+qyzTK8AFkE+8Jl7FxfA+0enL2XPVocVmz1E4S QZ3Hvy5+EAWzSG5YVLSK5wyny/bLMJYjlWazMcukImhMW92qJTTIRAi1dErxYLeZnTKI SiVLcUl0CPARdwZf7Nj+qZuWNN3QUSiziQlUhLPCetCtknCUN3bf4QjAevk6vOqqb5fj xPSw== X-Gm-Message-State: APjAAAVdX8s84e9TQmMzMaU9kLU75ypJu7D0CjtLoqrPw4riu9Sw//au Cp9/pnuyjTec1KhMOCtr1guup/mWw6g= X-Google-Smtp-Source: APXvYqyB0XE5286SS35atXbyKYnAqhk0U5dR6V+JlvSImHBYt6BsJVIRv8B0QGFHeWg3rghp7sz/HQ== X-Received: by 2002:a2e:7816:: with SMTP id t22mr2535320ljc.161.1576688003573; Wed, 18 Dec 2019 08:53:23 -0800 (PST) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com. [209.85.208.182]) by smtp.gmail.com with ESMTPSA id n23sm1442593lfa.41.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-f182.google.com with SMTP id j6so2928363lja.2 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" Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org 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 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 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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 9BC51C2D0CD for ; Wed, 18 Dec 2019 16:53:28 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6BA1124672 for ; Wed, 18 Dec 2019 16:53:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (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 6BA1124672 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 182AB89B70; Wed, 18 Dec 2019 16:53:27 +0000 (UTC) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) by gabe.freedesktop.org (Postfix) with ESMTPS id 237F689B70 for ; Wed, 18 Dec 2019 16:53:25 +0000 (UTC) Received: by mail-lf1-x141.google.com with SMTP id v201so2172804lfa.11 for ; Wed, 18 Dec 2019 08:53:25 -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=cpNNDN2QKOzPGYgmkqQur9R0jw13pYfw6cgCXxNqGDZWY0ZfiBjm7UsVaCDL1GfaAa NoKFW7Sqmf4rldrxAoFV5MUHzMQHQU8uKKjzk/kqG3jxUNBkIMLfTLe4b2fQfAyJ/fR6 09Mb7XY82jAWcKTorfDyQkGt3uD+98rslM/DSLX2oIrHAOWzdQ7+aaD+RXx1p4fBb/pe 3NgTUespzrR0Zosfu/qO61KAkxrvCLxV/w/mT7QpMxA4SLUFsp/8nRHPstIGp8WR/iLd e72hblvTy7e0hn2ESXCbeKRyOoBTKPB2ZmhxJ6nW5pqmwvzyOXsWqu3judUZor8uCEYM DBDw== X-Gm-Message-State: APjAAAVaJJavup085TJCwkAMjQxxuZRKZ3WMDKFvqFuT3ZqCjeGojyf1 lmwToht0mHqAIp1mUntul5S9xXToOY8= X-Google-Smtp-Source: APXvYqzzgXJlVT55TOFGW+33wldob5Q6C56zcZhUDAAk0ET7xYOxbKhxK1CvMtp8NFx2vhy9VyTkfg== X-Received: by 2002:a19:dc1e:: with SMTP id t30mr2443416lfg.34.1576688003713; Wed, 18 Dec 2019 08:53:23 -0800 (PST) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com. [209.85.208.179]) by smtp.gmail.com with ESMTPSA id y11sm1856762lfc.27.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-f179.google.com with SMTP id u1so2917107ljk.7 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 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ralph Campbell , David Airlie , "Kuehling, Felix" , "dri-devel@lists.freedesktop.org" , Christoph Hellwig , "linux-mm@kvack.org" , Jerome Glisse , "amd-gfx@lists.freedesktop.org" , "Deucher, Alexander" , Dan Williams , Andrew Morton , "linux-rdma@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 97D00C43603 for ; Wed, 18 Dec 2019 17:27:43 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 68C1B20717 for ; Wed, 18 Dec 2019 17:27:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (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 68C1B20717 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1D43B6E9B9; Wed, 18 Dec 2019 17:27:42 +0000 (UTC) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9CF1C89B70 for ; Wed, 18 Dec 2019 16:53:26 +0000 (UTC) Received: by mail-lf1-x143.google.com with SMTP id 15so2215752lfr.2 for ; Wed, 18 Dec 2019 08:53:26 -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=Xx70UTwt3/Il6Q0VbTzY12Z61sZxbojLyxqLv5mGla/c6dAD3YefPQDNh7hSMxtllC rJxSBMT7kZ1D4dcKKJkWg4VLWwMFTHZW203qzqwQcyMKOB8n8SHabnB4LweO3YRV5GuJ y7jrcgoPHBH7Bbu0Q/qtXTH/D+HSeKnBe29ywik7hM1+Sftfz2MY22hty3m0O+l66zl7 1pQ9Z1r2tnin77WktymgZoElqPXn9PvASzluDffFgbxN5WFcAyywuDfEX2atFdZpAXr0 BZQvGmND9o6vMLxhVMFxaBx5xbdicrff9+NtWGl9NQB+nbskYABepBuxsrkg99ZTHor5 J77Q== X-Gm-Message-State: APjAAAUL5ovsfug6AbAidl4YOvXnwfkVo+vpF/7GNKk+QrAHqrnMVwUv u3iT+SsCxycS1sksFD0dwFAs+gvcN5g= X-Google-Smtp-Source: APXvYqwXRsixO0NCOA51lqzPtJVcj1hDbMhvYJXC9B/3QLb/fIkQ6QJFkKhSO39ZqMc/7RVq0OxYDA== X-Received: by 2002:a19:2389:: with SMTP id j131mr2320913lfj.86.1576688003748; Wed, 18 Dec 2019 08:53:23 -0800 (PST) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com. [209.85.208.181]) by smtp.gmail.com with ESMTPSA id w19sm1413174lfl.55.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-f181.google.com with SMTP id k1so2269509ljg.1 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 X-Mailman-Approved-At: Wed, 18 Dec 2019 17:27:41 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ralph Campbell , David Airlie , "Kuehling, Felix" , "dri-devel@lists.freedesktop.org" , Christoph Hellwig , "linux-mm@kvack.org" , Jerome Glisse , "amd-gfx@lists.freedesktop.org" , "Deucher, Alexander" , Dan Williams , Andrew Morton , "linux-rdma@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" 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 _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx