Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4449787ioa; Wed, 27 Apr 2022 04:15:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzT2glZqQVvjdqMLO6Lp5ZONLHIpEms957LOJrQOepjRR0Jlmz9sJIF00myaDYj48A9HTYb X-Received: by 2002:a63:2a04:0:b0:3c1:5f7f:2d33 with SMTP id q4-20020a632a04000000b003c15f7f2d33mr478707pgq.69.1651058116841; Wed, 27 Apr 2022 04:15:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651058116; cv=none; d=google.com; s=arc-20160816; b=FPggRyi6eRcE+Rqda9eLVE60JtnnAyODZ+pgKClpyM/VIMkx8064CDfdrYqrXBmeEl c6yUvrXfHja6aSQ1HX8Wl1AREeDTVbDxjiVVHtv13P2QjrWvLHsSQ55B4JaDJRWOrYPB 4MnvU24dzhXsJGvjCKZ8GCJZMd04ddm/1qfbUMlJ42mIDk1FD0Ynr8adGEs4/8UwjcTA LTWrP3cIXnNXtQB6hxaH/hn5ktaXtPwwiaNmn7FZOlFYUokHd7E55cmjinFZ/wKXqkDW cerxGqXZF+FLqUdd1MfLmv9ZbYc72Qsmd/tr+MzJfK1wvz1jHaOLI2h4Y3N5lm90GDoG CKSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=8PYCrbxlCa6bNidJxmu8ER1YKrbYNO9HHV9iadmviGo=; b=jc0Mb030z6cvtxC6WOoIpr3Z+V0GNd5838c+ELanjYkYYT4ItIKXZfRVegAEfpIVFD jwdMeQ2+8Wv4dRg51VKtGFIMCwi6LMm7ZidsuvQOYoAIj35UrEDWIcPao/MKsqqJhaJI osFmxS6RfLBHIga7QwsfCQ3RObY/PlMnh5atJjwaPZiTsUgucM9aYp83JGRAqfWDZ88+ e3HJsDtAxCaBRZ/3Wfyf9EVdh+iBQ0aOTzkMjtYZ8+7ivYq0R6xRi+xiQv43EQfXzPan qmjKU2+Vl9UYiplSiM7ypglqV7Vr1ZLJaDaSo1aIVolHYjxn5+Bcp402y4POuttJrxFE Fz5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bfhDEV8F; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id m17-20020a63f611000000b003a9eb7ecffcsi1178890pgh.181.2022.04.27.04.15.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 04:15:16 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=bfhDEV8F; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1651A45499D; Wed, 27 Apr 2022 03:09:10 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237114AbiDZR4P (ORCPT + 99 others); Tue, 26 Apr 2022 13:56:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242353AbiDZR4L (ORCPT ); Tue, 26 Apr 2022 13:56:11 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C10D1208E; Tue, 26 Apr 2022 10:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650995583; x=1682531583; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=XqUIzyKlR1H4AWn7rRefqRtq3YT/aLsnxjGSzWgozcU=; b=bfhDEV8F5VghxEWFPhZOIWEfEtSXKE2Jkh1YVPEg0FWam01bhknSytoy IcwJ8z5cXX95dl82x0ufhyDP5dbnxFtHhBZdxquEgcWg9ZwFJ7MY+Rc/o aLIBQrqIe/qj61PRUzLq0pfbL9M+52m/moYCIvZMBGNNlV4mvc/uOvGx3 Ouk6YNBB7z/NV8ll7Wed8d+w/APACgwoTZybDQWQ1VxlMZosrVngIiEHB +7QDlyaCVbH27ezLpdcl76k6oOWRBCmw07yj1SlYSd6xjSiOzb5hBO1jo IJo6MhNobHBKPXekXKjxTdCFHhgb0/2pIrMkts2JXQWyOG9IOwjlmhFkv Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10329"; a="245595597" X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="245595597" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.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-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.