Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp873177pxb; Thu, 28 Jan 2021 02:22:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJyoTrI6E7sCd/LFuSRFLdHeNNhG3vXjMPv8HDWMj1CZliBDt8JnG0z4vHF60NQVmoeiBirm X-Received: by 2002:a05:6402:c92:: with SMTP id cm18mr13953791edb.367.1611829370302; Thu, 28 Jan 2021 02:22:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611829370; cv=none; d=google.com; s=arc-20160816; b=JJQW8UaOJ/6zpfp1hceyTqq4rNkpQ9WguvKA2RsTL/5iKeNP+zqv6RCC5uvvaHPepG KmN0vkmF5ssAgwRzuGurlxbVB/0M1BFIlb+ri/rzA3Z1+cduuidDERKHXZJHhhl+SLGo jh3Pw58wkvjDjzX8RG0mHcE9iMeAmHHubgHL33QumdaWg7PepKfIdcFU9thHk0PCMvj8 yQVJMvM/N506JWXNbIoWCpd6QEMeYr3uZYRxVEF3y3COq95JioNF2eakBuy2F4t3PEpj 8o/l8L36RSO0W0vugQL8coP/gk9pP68UEGZE4kD5FE5/Q0ocOou5F6+cMAiiFeelrCPZ Enow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=iDnJWOkOFmVooLwW3iLEaR7P3zzZQ3ejRFAmfGsUQr4=; b=Gojk264v0ctPxwgoFtrp8wtVnv5Dd+XEPHrTq6L2e9tOt4UrfTLvK2noOd1eS8QFnf ZBI6u/Z1qwv4eyApy4PWCGfbhVxD6GX1sAbZ1DWvPv4LLNSM+g1/tPRF93WUfEzb2SMQ cQ0FIkMIqaeHrOsrc+bDrpzj2VDszjB5M8RxlHur8lC0vq3RfQgDIAAcbnK1S6gCOrHd aDiBOYymUr8BSZOczcQw42MhEf2gWyO5y70OAs47HTOQteHCs8FH7MPMU3TrGnEVedxL nm1P5FccweK4dEfIOqZjnn0xjgE+M0wXc8yxNdoZQgLgNFj2Tb4Papc4TzsfMFMXhn+T Zg2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nm5BKmFV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u15si2605822edt.339.2021.01.28.02.22.26; Thu, 28 Jan 2021 02:22:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nm5BKmFV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232161AbhA1KSs (ORCPT + 99 others); Thu, 28 Jan 2021 05:18:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232406AbhA1KSj (ORCPT ); Thu, 28 Jan 2021 05:18:39 -0500 Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0E4CC061574 for ; Thu, 28 Jan 2021 02:17:58 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id j21so3061497pls.7 for ; Thu, 28 Jan 2021 02:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iDnJWOkOFmVooLwW3iLEaR7P3zzZQ3ejRFAmfGsUQr4=; b=nm5BKmFVtD4KaRt5cIVds+MA9Jot7JyVBBQlKOiIydPan7p4oiIckxq+KyaLJB00Nb 02R7FW7Nhwv0hq5iOD6LJ17h0XWvm06qIGYbm2WmtO/Tn09MR7c4tndTq442s5RDB+XL DnHE25BG6MFgiA/H3jKqZmu1WufG3BwQdn6/K29IdWiUv+DlMRPnNb4pTRQyPyMRbK2Y 4moat9o9wHsLX58rBcoiAhwVAmQEK2ApkBRK57UX5tn8YgMAzkxXhrhGIxOP4Adxooog J1i1Htj7RYZdVMSvZem232qaUb8MU1QencicHcQRxb3ALwwy7I6WbB7G9VakU1HYxCHh wRgA== 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=iDnJWOkOFmVooLwW3iLEaR7P3zzZQ3ejRFAmfGsUQr4=; b=UG5tD8Dot5vXV1iJTjMVF+WZlPpckcYGHxohZyDK9D9LFxN9nscc31IrKzk399jh0z pdaQwKkp/hu/Ba9UsyHld4kiMfOkcS9ROo/uLEm1uz4myPx78/Rn7h9nIIfrd2eoOnPu 2+8xIYZaCdST3T53Hcid6365vgPLvl7tuC9Q/zU8aY1mRZYWOeRjKl6yrPErgBBtv4fG SOzv0AC/gpNSBktETbxWWVbenLway/UXjWAl3zJ8KbguJa6138C0Fl88TK+B4BLEsy7d rcxZPSX85axBOgzg8NEuBBu3fsDHoriE2oPZAZjK7DF0TWTQeDm+3tn+rBmf0QSFi5Fe U2cQ== X-Gm-Message-State: AOAM530tlhqlstqLDZDXygRzAN+9HNh6fWJeEk2URBoUlDixFj4n9/I5 CRX8SwgimaO7PoJszSTag0PmbW4ZyKl2bsmhzZIIMZviJw8= X-Received: by 2002:a17:90a:644a:: with SMTP id y10mr10741619pjm.129.1611829078364; Thu, 28 Jan 2021 02:17:58 -0800 (PST) MIME-Version: 1.0 References: <20210126171141.122639-1-paul.gortmaker@windriver.com> <20210126171141.122639-4-paul.gortmaker@windriver.com> <20210127080206.GE23530@windriver.com> In-Reply-To: From: Andy Shevchenko Date: Thu, 28 Jan 2021 12:17:42 +0200 Message-ID: Subject: Re: [PATCH 3/8] lib: bitmap: fold nbits into region struct To: Yury Norov Cc: Paul Gortmaker , Andy Shevchenko , Linux Kernel Mailing List , Li Zefan , Ingo Molnar , Thomas Gleixner , Josh Triplett , Peter Zijlstra , "Paul E. McKenney" , Frederic Weisbecker , Rasmus Villemoes Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 28, 2021 at 2:52 AM Yury Norov wrote: > On Wed, Jan 27, 2021 at 12:02 AM Paul Gortmaker > wrote: ... > > So, this change was added because Yury suggested that I "..store > > nmaskbits in the struct region, and avoid passing nmaskbits as a > > parameter." > > > > To which I originally noted "I considered that and went with the param > > so as to not open the door to someone possibly using an uninitialized > > struct value later." > > struct region is purely internal structure. It's declared on stack and filled > field-by-field using helpers. 'Someone' misusing the structure doesn't exist > because the structure doesn't exist out of the scope. > > > https://lore.kernel.org/lkml/20210122044357.GS16838@windriver.com/ > > > > Looking back, I had a similar thought as to yours, it seems... > > > > I am also thinking more and more that nbits doesn't belong in the > > region anyway - yes, a region gets validated against a specific nbits > > eventually, but it doesn't need an nbits field to be a complete > > specification. The region "0-3" is a complete specification for "the > > 1st four cores" and is as valid on a 4 core machine as it is on a 64 core > > machine -- a validation we do when we deploy the region on that machine. > > > > I will set this change aside and get the nbits value to getnum() another > > way, and leave the region struct as it was -- without a nbits field. > > > > This will also resolve having the macro handling of region that you were > > not really liking. > Region is a convenient structure. Adding nbits into it helps to remove > validation > logic from bitmap_set_region(), so it's worth doing this. > > Can you please have it unchanged? I have a compromise proposal here, i.e. why not to create a wrapper structure like struct bitmap_region { unsigned int nbits; struct region r; }; ? At least it will solve my concern and still be a local structure on the stack without adding new parameters to called functions. -- With Best Regards, Andy Shevchenko