Received: by 2002:a05:7412:251c:b0:e2:908c:2ebd with SMTP id w28csp1926020rda; Tue, 24 Oct 2023 07:26:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHdVhg+HHFO3j54Z0k2jtZL5rY81SDhBGyTKS9V/cK0bvmzs7c5t9NrHU28g01J1ulgq0Tp X-Received: by 2002:a17:902:d506:b0:1c3:c127:540 with SMTP id b6-20020a170902d50600b001c3c1270540mr11300794plg.29.1698157610883; Tue, 24 Oct 2023 07:26:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698157610; cv=none; d=google.com; s=arc-20160816; b=ZnyJmzQeU63s0OYVLLWySDsHw188kEXaUC2I8iKXtAdfuk09Ufl4DsTkjzv+U1f6E5 GKk64YPEXEkwaK9+viBEAEgvMxkxp2uW/x28XF/CuVxBMfPQIFdOAI/eRwauc11eiT5I wltf0BM8A3NeAUM8WVvMA0mP5sHKUgxKaE0NgwPHR+IfGVi3mVRGOkw0cnPRx1u44U8k zAJnL4onLPH6bpoEoDKF7rVh9z5a/Hrv/Seiq0/idhRLJy7/zd3SkAyPhkRmjhtr43jA G36U181ybNrJk4ATAWFdr2DJLza2NMdXHMYTfUQYMUKR57rM8ye4y4enDnS08r1Eo8Mh 6Cww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=bYYfTpskKOTq+BPUdzQPGs17qQYfAtAWoJydbRZLn70=; fh=fQfnlToAg3k5MM2KV5NwewUQS9y41Q4MAgfFrlgy2cU=; b=nwFjq75iOcZbUuU4EYHubOpw7uJJYrJRyVCTmxSsbvT7LjPFaCMzZ9Zb9CU+5Tg3WL 7v9OOibQvJW/sseeobW88g8yHVEYSApApPbpLlhK6JT9fnxBnsoLAUhf4+wuWg9gjkL9 p3i60hGoIz3rQlntkuHBL4V4Xi/9w9jur/822twiFQHRQOguqi3bxYvKFSb/RaVSSV3R yKKRD8KvyQLzaqGYXoGKiPWD3JAwTxCHzG3dTKjU+QZeEqa+0kLDnmwcDDZBfIMZIA50 s1dAuLs9u3BfmrnWhHJJ7HXrZbFho0vgLAhmkv+JEfC2MDlHF6GjypAGgNCwXM/DGtBD rEiA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id k5-20020a170902c40500b001c9b5a90a92si8576120plk.344.2023.10.24.07.26.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Oct 2023 07:26:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 34083805CD9E; Tue, 24 Oct 2023 07:26:46 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234706AbjJXO0e (ORCPT + 99 others); Tue, 24 Oct 2023 10:26:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343742AbjJXO0c (ORCPT ); Tue, 24 Oct 2023 10:26:32 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD490E8 for ; Tue, 24 Oct 2023 07:26:30 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6600,9927,10873"; a="389918644" X-IronPort-AV: E=Sophos;i="6.03,248,1694761200"; d="scan'208";a="389918644" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2023 07:26:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10873"; a="787800546" X-IronPort-AV: E=Sophos;i="6.03,248,1694761200"; d="scan'208";a="787800546" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga008.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2023 07:26:22 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.97-RC3) (envelope-from ) id 1qvIMM-00000008Ixi-3mgW; Tue, 24 Oct 2023 17:26:18 +0300 Date: Tue, 24 Oct 2023 17:26:18 +0300 From: Andy Shevchenko To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, keescook@chromium.org, rostedt@goodmis.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 01/39] lib/string_helpers: Add flags param to string_get_size() Message-ID: References: <20231024134637.3120277-1-surenb@google.com> <20231024134637.3120277-2-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231024134637.3120277-2-surenb@google.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Tue, 24 Oct 2023 07:26:46 -0700 (PDT) (Minimized the list of people for my review / comments) On Tue, Oct 24, 2023 at 06:45:58AM -0700, Suren Baghdasaryan wrote: > From: Kent Overstreet > > The new flags parameter allows controlling > - Whether or not the units suffix is separated by a space, for > compatibility with sort -h > - Whether or not to append a B suffix - we're not always printing > bytes. ... > string_get_size(nblocks, queue_logical_block_size(q), > - STRING_UNITS_10, cap_str_10, sizeof(cap_str_10)); > + 0, cap_str_10, sizeof(cap_str_10)); This doesn't seem right (even if it works). We shouldn't rely on the implementation details. ... > - string_get_size(sdkp->capacity, sector_size, > - STRING_UNITS_10, cap_str_10, sizeof(cap_str_10)); > + string_get_size(sdkp->capacity, sector_size, 0, > + cap_str_10, sizeof(cap_str_10)); Neither this. ... > -/* Descriptions of the types of units to > - * print in */ > -enum string_size_units { > - STRING_UNITS_10, /* use powers of 10^3 (standard SI) */ > - STRING_UNITS_2, /* use binary powers of 2^10 */ > +enum string_size_flags { So, please add UNITS_10 as it is now. It will help if anybody in the future wants to add, e.g., 8-base numbers. > + STRING_SIZE_BASE2 = (1 << 0), > + STRING_SIZE_NOSPACE = (1 << 1), > + STRING_SIZE_NOBYTES = (1 << 2), > }; Please, add necessary comments. ... > +enum string_size_units { > + STRING_UNITS_10, /* use powers of 10^3 (standard SI) */ > + STRING_UNITS_2, /* use binary powers of 2^10 */ > +}; And what a point now in having these? I assume you need to split this to a few patches: 1) rename parameter to be a flags without renaming the definitions (this will touch only string_helpers part); 2) do the end job by renaming it all over the drivers; 3) add the other flags one-by-one (each in a separate change); 4) use new flags where it's needed; Also see below. ... > static const char *const units_10[] = { > - "B", "kB", "MB", "GB", "TB", "PB", "EB", "ZB", "YB" > + "", "k", "M", "G", "T", "P", "E", "Z", "Y" > }; > static const char *const units_2[] = { > - "B", "KiB", "MiB", "GiB", "TiB", "PiB", "EiB", "ZiB", "YiB" > + "", "Ki", "Mi", "Gi", "Ti", "Pi", "Ei", "Zi", "Yi" > }; Ouch, instead of leaving this and actually "cutting the letter" with NO* flags, you did something different. ... Now the main part. Since in 50+% cases (I briefly estimated, it may be more) this is used in printf() why not introducing a new pointer extension for that? Yes, it may be done separately, but it will look like a double effort to me. Instead it might give us a possibility to scale w/o touching users each time we want to do something and at the same time hide this complete API under printf() implementation. -- With Best Regards, Andy Shevchenko