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 CB1A2C77B7F for ; Wed, 3 May 2023 09:45:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36D306B0071; Wed, 3 May 2023 05:45:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F6616B0072; Wed, 3 May 2023 05:45:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BE606B0074; Wed, 3 May 2023 05:45:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by kanga.kvack.org (Postfix) with ESMTP id E753B6B0071 for ; Wed, 3 May 2023 05:45:01 -0400 (EDT) Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-74e0180b7d3so222662485a.2 for ; Wed, 03 May 2023 02:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683107101; x=1685699101; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vu1/caV96gPScaPWMCtnkWIUIUcxiUGOiQt9hLifgPw=; b=VhDxBqzjRGO4xEvrUoTELhpqFpNqdt+CVDZ+RfOG21FgkmixgwMMdwK/NneQ7mOOcc yhGPzgIBNau3G+2U9K7Xt4a9gdggrYOnkpWS/wNla11FYYg09l2IaImcnU5+b9MibRcR k9v90h1Rsd7vskA6KQe8SRuvpU0sLUxitSFfsDPXj87uFGSdWAnrfcOx/eIuqMMyzqhk CZB3LVF8x3HzsHEtVrXZagn8mwxC1GFztjcfWkPZzT8tLdcTHbvRug9Ltx2dxhrAfuC2 +waxUOke8lDu/8kEPIx91rOnvSt36w2a70UZk/8uywir3znA4RllKMN+w9ENvaPVPtXq x7ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683107101; x=1685699101; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vu1/caV96gPScaPWMCtnkWIUIUcxiUGOiQt9hLifgPw=; b=Faqu8CROKKG1jYrMWjHaxdMgY2lF31m9Zgxda+TLylWvUkOAZmA84EwGgpnUtXZhAt idMZz9NR+bA7MWlQqkBzckssFKM8iPh1Ar6plYfjcKXKgbidflMuCJ57BctHELhYEZXH PzScTZlsS5wFqC6fCad7buJPzNfL77M3Eqinp3sP4+NKwUNsDp8PmevKDtmjrZpehbMR zw3BmyyvsEKpovS4u1dnWbiHWpKqOitUfxaSfOx1RzHE7ss/zUE9w2iimbE37vhfUi/b Jrv49/nkcYo+6S4ofot7yiXQmuDUnjew96g4B4HuizZTJbG6EvEfLJzShtBi40C2u2s3 BB1g== X-Gm-Message-State: AC+VfDyoYgQmN8fG0DoH3jWz5OSDHdGCHn8o3BG+viK5HnO4e3Wc65CG xdBBlVsF8f5Zk4j4bN4q+BLf0+M5DoRXu2aRFD8= X-Google-Smtp-Source: ACHHUZ6yi+LLZmqHyLDaoBpk27DTVexvbnD/0m840PDBVgRRMFVAguYf3NnMhxz4oEixavoWuRx1ThmZystGlNmkfIs= X-Received: by 2002:a05:6214:2629:b0:61b:17bd:c603 with SMTP id gv9-20020a056214262900b0061b17bdc603mr10563566qvb.9.1683107101117; Wed, 03 May 2023 02:45:01 -0700 (PDT) MIME-Version: 1.0 References: <20230501165450.15352-1-surenb@google.com> <20230501165450.15352-2-surenb@google.com> <2f5ebe8a9ce8471906a85ef092c1e50cfd7ddecd.camel@HansenPartnership.com> <20230502225016.GJ2155823@dread.disaster.area> In-Reply-To: From: Andy Shevchenko Date: Wed, 3 May 2023 12:44:24 +0300 Message-ID: Subject: Re: [PATCH 01/40] lib/string_helpers: Drop space in string_get_size's output To: Vlastimil Babka Cc: Dave Chinner , James Bottomley , Kent Overstreet , Suren Baghdasaryan , akpm@linux-foundation.org, mhocko@suse.com, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, ldufour@linux.ibm.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org, Andy Shevchenko , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , "Michael S. Tsirkin" , Jason Wang , =?UTF-8?B?Tm9yYWxmIFRyw6/Cv8K9bm5lcw==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Wed, May 3, 2023 at 12:28=E2=80=AFPM Vlastimil Babka wr= ote: > > On 5/3/23 00:50, Dave Chinner wrote: > > On Tue, May 02, 2023 at 07:42:59AM -0400, James Bottomley wrote: > >> On Mon, 2023-05-01 at 23:17 -0400, Kent Overstreet wrote: > >> > On Mon, May 01, 2023 at 10:22:18PM -0400, James Bottomley wrote: > >> > > It is not used just for debug. It's used all over the kernel for > >> > > printing out device sizes. The output mostly goes to the kernel > >> > > print buffer, so it's anyone's guess as to what, if any, tools are > >> > > parsing it, but the concern about breaking log parsers seems to be > >> > > a valid one. > >> > > >> > Ok, there is sd_print_capacity() - but who in their right mind would > >> > be trying to scrape device sizes, in human readable units, > >> > >> If you bother to google "kernel log parser", you'll discover it's quit= e > >> an active area which supports a load of company business models. > > > > That doesn't mean log messages are unchangable ABI. Indeed, we had > > the whole "printk_index_emit()" addition recently to create > > an external index of printk message formats for such applications to > > use. [*] > > > >> > from log messages when it's available in sysfs/procfs (actually, is > >> > it in sysfs? if not, that's an oversight) in more reasonable units? > >> > >> It's not in sysfs, no. As aren't a lot of things, which is why log > >> parsing for system monitoring is big business. > > > > And that big business is why printk_index_emit() exists to allow > > them to easily determine how log messages change format and come and > > go across different kernel versions. > > > >> > Correct me if I'm wrong, but I've yet to hear about kernel log > >> > messages being consider a stable interface, and this seems a bit out > >> > there. > >> > >> It might not be listed as stable, but when it's known there's a large > >> ecosystem out there consuming it we shouldn't break it just because yo= u > >> feel like it. > > > > But we've solved this problem already, yes? > > > > If the userspace applications are not using the kernel printk format > > index to detect such changes between kernel version, then they > > should be. This makes trivial issues like whether we have a space or > > not between units is completely irrelevant because the entry in the > > printk format index for the log output we emit will match whatever > > is output by the kernel.... > > If I understand that correctly from the commit changelog, this would have > indeed helped, but if the change was reflected in format string. But with > string_get_size() it's always an %s and the change of the helper's or a > switch to another variant of the helper that would omit the space, wouldn= 't > be reflected in the format string at all? I guess that would be an argume= nt > for Andy's suggestion for adding a new %pt / %pT which would then be (Note, there is no respective %p extension for string_get_size() yet. %pt is for time and was used as an example when its evolution included a change like this) > reflected in the format string. And also more concise to use than using t= he > helper, fwiw. --=20 With Best Regards, Andy Shevchenko