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 E8C63C433F5 for ; Mon, 25 Apr 2022 04:19:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B08E6B00CA; Mon, 25 Apr 2022 00:19:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35FCC6B00CB; Mon, 25 Apr 2022 00:19:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2276C6B00CC; Mon, 25 Apr 2022 00:19:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 0F9466B00CA for ; Mon, 25 Apr 2022 00:19:14 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B5CFE25607 for ; Mon, 25 Apr 2022 04:19:13 +0000 (UTC) X-FDA: 79394096586.31.C107325 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) by imf13.hostedemail.com (Postfix) with ESMTP id 3C3F02001E for ; Mon, 25 Apr 2022 04:19:08 +0000 (UTC) Received: by mail-qk1-f172.google.com with SMTP id y129so9988530qkb.2 for ; Sun, 24 Apr 2022 21:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=n9ZQHKz6biJiRkpy+CyyBSek4fjy21imjdDmRA8Vqgw=; b=cmnAJJkP34bjVns2uO/86rkj5RTyiJm45vA+lAwj5O1/o0Y0+K/ZQz858LHcAhf/Wj o33vdISVSpM7OTXmNjeVFiQpYuzIAYHFTIFr/IYykpp2p63xBZDt34cM8T6iFOltM7N8 BTBERl3etwNlD+7WAHI7TqcOWnntTf1hJQFhTL/j3Bi5MkhQ/TXngcZTR0s9OshoZPXm opl0oTVWYCec68WYkUBR1YC+i11/f3aNqqKMbRxnS2w5mpyFYdu7LWtdLCtiaIerJMuz ixhVtMKpJYI4FqxSKCKzcGJWRJb/98HN+0dlS3m8onn1Pv0gnODJbuUKWmbSuMFM8sXb fDcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=n9ZQHKz6biJiRkpy+CyyBSek4fjy21imjdDmRA8Vqgw=; b=cbdf15b/hFZHaoPLftkRdeZyMusDPd9IE5wFRVlvXpEVBfHoQNxxzImDrkvsrzPIjM b4TAzhjkeEmydmk4ymTH80c/NVMsCOGM/n+Og+3Xf4DiMJnWIy9JTdn0ChhG8n+eD9n9 7iuLNVvwSYZiGKACjZLyjZFrkVhZGBgy2CIjU6m33HSROcuPzf69YL3WTtuwNlBktU4M eJPCnkMmx3tJ380pjmjqsQd5pnNu/6s3LVXc7cvkRtY/5NipFrctVJLx/fuvq4FlYVCM 17dEU0PCuQgJSHBeLRA36eY2STzsxiag/+tcgI+uOkOZErVj1UNMe3f5qvsqAbwxoUrN 9A0Q== X-Gm-Message-State: AOAM53267v8ClKbnoL5He9VPeTnI+QL5KOtTTB0X/AqRt2z/Fgag2cnr 1UZkSBBCfitvDvxP2G9UMQ== X-Google-Smtp-Source: ABdhPJxeI09oROlDGdyr6/aGBGZksem4gbPjLwqSs0XVQfJosORnc9e+ZOIM168DGIgRrzo9YgWVhA== X-Received: by 2002:a05:620a:13a5:b0:69e:e3b1:91a0 with SMTP id m5-20020a05620a13a500b0069ee3b191a0mr8995546qki.5.1650860352586; Sun, 24 Apr 2022 21:19:12 -0700 (PDT) Received: from moria.home.lan (c-73-219-103-14.hsd1.vt.comcast.net. [73.219.103.14]) by smtp.gmail.com with ESMTPSA id c21-20020ac87dd5000000b002f36347ddabsm3300316qte.77.2022.04.24.21.19.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Apr 2022 21:19:11 -0700 (PDT) Date: Mon, 25 Apr 2022 00:19:09 -0400 From: Kent Overstreet To: Matthew Wilcox Cc: Joe Perches , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, hch@lst.de, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-clk@vger.kernel.org, linux-tegra@vger.kernel.org, linux-input@vger.kernel.org, roman.gushchin@linux.dev Subject: Re: [PATCH v2 1/8] lib/printbuf: New data structure for heap-allocated strings Message-ID: <20220425041909.hcyirjphrkhxz6hx@moria.home.lan> References: <20220421234837.3629927-1-kent.overstreet@gmail.com> <20220421234837.3629927-7-kent.overstreet@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=cmnAJJkP; spf=pass (imf13.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.222.172 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3C3F02001E X-Stat-Signature: mfs4c65z6cyttwb4cdkm6nkrbtt9t4qk X-HE-Tag: 1650860348-996226 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 Mon, Apr 25, 2022 at 03:44:34AM +0100, Matthew Wilcox wrote: > On Sun, Apr 24, 2022 at 04:46:03PM -0700, Joe Perches wrote: > > > + * pr_human_readable_u64, pr_human_readable_s64: Print an integer with human > > > + * readable units. > > > > Why not extend vsprintf for this using something like %pH[8|16|32|64] > > or %pH[c|s|l|ll|uc|us|ul|ull] ? > > The %pX extension we have is _cute_, but ultimately a bad idea. It > centralises all kinds of unrelated things in vsprintf.c, eg bdev_name() > and clock() and ip_addr_string(). And it's not remotely discoverable. I didn't realize we had bdev_name() available as a format string until just now or I would've been using it! > Really, it's working around that we don't have something like Java's > StringBuffer (which I see both seq_buf and printbuf as attempting to > be). So we have this primitive format string hack instead of exposing > methods like: > > void dentry_string(struct strbuf *, struct dentry *); Exactly! > as an example, > if (unlikely(ino == dir->i_ino)) { > EXT4_ERROR_INODE(dir, "'%pd' linked to parent dir", > dentry); > return ERR_PTR(-EFSCORRUPTED); > } > > would become something like: > > if (unlikely(ino == dir->i_ino)) { > struct strbuf strbuf; > strbuf_char(strbuf, '\''); > dentry_string(strbuf, dentry); > strbuf_string(strbuf, "' linked to parent dir"); > EXT4_ERROR_INODE(dir, strbuf); > return ERR_PTR(-EFSCORRUPTED); > } > > which isn't terribly nice, but C has sucky syntax for string > construction. Other languages have done this better, including Rust. Over IRC just now you proposed "%p(%p)", dentry_name, dentry - I'm _really_ liking this idea, especially if we can get glibc to take it. Then your ext4 example becomes just if (unlikely(ino == dir->i_ino)) { EXT4_ERROR_INODE(dir, "'%p(%p)' linked to parent dir", dentry_name, dentry); return ERR_PTR(-EFSCORRUPTED); } And you can cscope to the pretty-printer! And dentry_name becomes just void dentry_name(struct printbuf *out, struct dentry *dentry) { ... } Which is quite a bit simpler than the current definition. Sweeeeeet.