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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF491C433FE for ; Tue, 26 Apr 2022 17:53:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 33F736B0073; Tue, 26 Apr 2022 13:53:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C6806B0074; Tue, 26 Apr 2022 13:53:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1412F6B0075; Tue, 26 Apr 2022 13:53:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 00C016B0073 for ; Tue, 26 Apr 2022 13:53:05 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C791427011 for ; Tue, 26 Apr 2022 17:53:05 +0000 (UTC) X-FDA: 79399776330.16.668CC50 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf11.hostedemail.com (Postfix) with ESMTP id E7BF64003E for ; Tue, 26 Apr 2022 17:53:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650995584; x=1682531584; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=XqUIzyKlR1H4AWn7rRefqRtq3YT/aLsnxjGSzWgozcU=; b=LX7xDZ1xAyLkWceQNc7NBvEPDRelL52pFHl+AL43B0HCARn8K8EpmYRC 9DEgOGosWJcmsAundmimsZpSqNcWAWovMkI5KJYTSxCt1KVLKhcTgWDy6 ZWnQg1rmlWDCML0SOCgqCuohnzEJtMFTo/+xY2mVJdE3QIa3fdrLHeiKx 7msl3F4fSUUvJQoHBhB8Bj9zuX40xlOyNEArxeh8Xr2mwus9RvB/5DTty Amp0JN1LRN77fK0c57Vwa4NUXSbsY3Du2WWOdKiQtUeYiJcNbL/F9RAFF /4K84Teal1hfOhcEIClvsXd+evuVTRcAC7vmmtVknr/c7fm5DfPEcj5gw w==; X-IronPort-AV: E=McAfee;i="6400,9594,10329"; a="290818898" X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="290818898" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 10:53:03 -0700 X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="580064081" Received: from dsocek-mobl2.amr.corp.intel.com (HELO [10.212.69.119]) ([10.212.69.119]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 10:53:00 -0700 Message-ID: <90b448ba-2d5c-b0a2-4716-a8470fe09af0@intel.com> Date: Tue, 26 Apr 2022 10:55:43 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v7 5/8] x86/e820: Refactor e820__range_remove Content-Language: en-US To: Martin Fernandez Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ardb@kernel.org, dvhart@infradead.org, andy@infradead.org, gregkh@linuxfoundation.org, rafael@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, daniel.gutson@eclypsium.com, hughsient@gmail.com, alex.bazhaniuk@eclypsium.com, alison.schofield@intel.com, keescook@chromium.org References: <20220425171526.44925-1-martin.fernandez@eclypsium.com> <20220425171526.44925-6-martin.fernandez@eclypsium.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E7BF64003E X-Stat-Signature: y3umzsz578fp16dshg8cmi8j86wfmw49 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LX7xDZ1x; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf11.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=dave.hansen@intel.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1650995581-20737 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 4/26/22 10:37, Martin Fernandez wrote: >> Also, in general, the naming is a bit verbose. You might want to trim >> some of those names down, like: >> >>> +static bool __init crypto_updater__should_update(const struct e820_entry >>> *entry, >>> + const void *data) >>> +{ >>> + const struct e820_crypto_updater_data *crypto_updater_data = >>> + (const struct e820_crypto_updater_data *)data; > Yes I agree on this. Do you have any suggestions for these kind of > functions? I want to explicitly state that these functions are in some of > namespace and are different of the other ones. > > In the end I don't think this is very harmful since these functions are one-time > used (in a single place), is not the case that you have to use them everywhere.. Let's just start with the fact that this is a pointer to a structure containing an enum that represents a single bit. You could just pass around an address to a bool: bool crypto_capable = *(bool *)data; or even just pass and use the 'void *data' pointer as a value directly: bool crypto_capable = (bool)data; That, for one, would get rid of some of the naming craziness. If it were me, and I *really* wanted to keep the full types, I would have just condensed that line down to: struct e820_crypto_updater_data *crypto_data = data; Yeah, it _can_ be const, but it buys you practically nothing in this case and only hurts readability.