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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F28A1C00140 for ; Mon, 8 Aug 2022 17:44:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244339AbiHHRoJ (ORCPT ); Mon, 8 Aug 2022 13:44:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244343AbiHHRnf (ORCPT ); Mon, 8 Aug 2022 13:43:35 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC355B51 for ; Mon, 8 Aug 2022 10:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1659980614; x=1691516614; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=eZHz5AZts8pa+4dAgLDzj+RDlAzwOdbJVrXvXp0Rcms=; b=WfL43eYuI3KWCs5hUgkt+oYHtcri+hAusIikoE4nQd7hW7eQOSV/U/zl aIj4HPf0AZ1kGVWpxjrcZBReISUp5iIsiBfAdgZ1Y4jN0XKJTwkPTv8/j Lc8A/t04jO9AthfJItzKuBXslRCm/SGsRnuXtpv//wIjYE5qFdp8pJReS OJl/amiW7l6A4OouBVNwKyvdOdpiIaPD+lftPTIiY7L2TdGb+NRbHbFR/ vWXh11Gn+wx6fE/wPL+hGAo9KkOqKEgW+EdVB5bPz5y8vp95zOsPsKEb0 EPKjnFYoj5yJ/0bkIZVFHHv5IoLhT9S/aWTrtiId5wMb3RIJNM+connEI Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10433"; a="273703180" X-IronPort-AV: E=Sophos;i="5.93,222,1654585200"; d="scan'208";a="273703180" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2022 10:43:34 -0700 X-IronPort-AV: E=Sophos;i="5.93,222,1654585200"; d="scan'208";a="604452861" Received: from sankarka-mobl1.amr.corp.intel.com (HELO [10.212.251.15]) ([10.212.251.15]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2022 10:43:34 -0700 Message-ID: Date: Mon, 8 Aug 2022 10:43:35 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [RFC PATCH 1/5] entry: Pass pt_regs to irqentry_exit_cond_resched() Content-Language: en-US To: Borislav Petkov , Ira Weiny Cc: Rik van Riel , Dave Hansen , x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com References: <20220805173009.3128098-1-ira.weiny@intel.com> <20220805173009.3128098-2-ira.weiny@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/8/22 10:38, Borislav Petkov wrote: > On Mon, Aug 08, 2022 at 10:34:19AM -0700, Ira Weiny wrote: >> I thought about that but generally have been steered away from using bool >> arguments like this. > The reason being? Might have been me. Function calls that look like this: foo(&ptr, false, true, false, true, 1, 0); are incomprehensible. A true/false is effectively a magic number here and you have to go looking at the code implementing 'foo()' or at least the declaration hoping that the variable names help (if the declaration has variable names). I think I've encouraged Ira to do something like this instead: enum foo_mode { MODE_BAR, MODE_BAZ } where the call ends up looking like: foo(&ptr, MODE_BAR); which is much more self-documenting.