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 D82C9C433F5 for ; Fri, 22 Apr 2022 21:51:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B3706B0073; Fri, 22 Apr 2022 17:51:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 362296B0074; Fri, 22 Apr 2022 17:51:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2028E6B0075; Fri, 22 Apr 2022 17:51:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 0E93E6B0073 for ; Fri, 22 Apr 2022 17:51:50 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D66CD20E02 for ; Fri, 22 Apr 2022 21:51:49 +0000 (UTC) X-FDA: 79385862738.01.6427446 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf16.hostedemail.com (Postfix) with ESMTP id 79BCC18003C for ; Fri, 22 Apr 2022 21:51:47 +0000 (UTC) Received: by mail-qt1-f181.google.com with SMTP id l7so144678qtq.6 for ; Fri, 22 Apr 2022 14:51:49 -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=RZMfk42e8wN88X1x4Oc4ckY2xJ8vXIPWfHgWdfKTn9M=; b=OSzfMYbMeDyu2ee3SkdVdwdxHDs6Jzcx2Ft5LhsurqKR50qJ8HRKBjD3f87T0XNmxR qPnidw8ZJGlkLY4hMiMsUUqST228rD37ocmfljP7rOdrbzZs3xADUHms29i9T65N5q9E clMgoBeG13AcWf9ZZfieqatqAf8Yj3w3rxiAT2PbzEXyVNfRiReGT+XgQbJekBqIWe5q P/XFEhR+21IEscdN+hf34slbakBnAe7UATNkKqG4TVmxXH+UjyXh7SddnQ7HDYvfH9Nt OEqb8324QrpnTlQriByF9ZcZf/Go3TvUITwT8PsNgo2rtCmUHHWiuk1BEArJwiB3TjTB bExQ== 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=RZMfk42e8wN88X1x4Oc4ckY2xJ8vXIPWfHgWdfKTn9M=; b=6Uxa+KVIB0MFVKpWkxH/aKMjQvHt4wRajWjU+Rmy1T+WutqCJPCIS4p9yaP2Ijesy/ CLa7DKIdYFrzlgYOULHN8RpQT/0beVNm1jXNNclzjv+yq4DzzVb1zfIOyBGwzUs8tCVy CDc7doaeroJ/Gf/HdLePuAE0hAKI4tbIlwfBBV5wImIQdnKNcGV7VZSYibq60UpmtZDn ibj+/G1uB8deQUnzplpxdH/SpD+y0JJ2+EG/JH5rpDD8+GUBaK5o+o09ZR7VpBo4guxA GFX0+iXpYUIV+fy2+zw08XIpFE3boj9S0WItjd179b7GB/NYMSV0Jl/220+BaBMFA1kH Nouw== X-Gm-Message-State: AOAM532omfybusSnUHeCF/PQvjhkf+UY+CBcw/TVIg5e+LMoo7kQiHqe SKfDx7MZcIgzisHCNAYtLcHoi5cQQwO0 X-Google-Smtp-Source: ABdhPJxyyCkFj9u8Z2ocvKIb99chaQNgfvpROYCjFGnjIdmRADHMMNVhTGFRGUajfZ+aBtu4TsJEvA== X-Received: by 2002:a05:622a:1a86:b0:2f3:4be4:42dd with SMTP id s6-20020a05622a1a8600b002f34be442ddmr4854803qtc.55.1650664308682; Fri, 22 Apr 2022 14:51:48 -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 y20-20020a05622a121400b002eefd7bf5basm2080434qtx.63.2022.04.22.14.51.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 14:51:48 -0700 (PDT) Date: Fri, 22 Apr 2022 17:51:46 -0400 From: Kent Overstreet To: Steven Rostedt Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, 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: <20220422215146.i663tn6zzn6blzo3@moria.home.lan> References: <20220421234837.3629927-7-kent.overstreet@gmail.com> <20220422042017.GA9946@lst.de> <20220422052208.GA10745@lst.de> <20220422113736.460058cc@gandalf.local.home> <20220422193015.2rs2wvqwdlczreh3@moria.home.lan> <20220422153916.7ebf20c3@gandalf.local.home> <20220422203057.iscsmurtrmwkpwnq@moria.home.lan> <20220422164744.6500ca06@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220422164744.6500ca06@gandalf.local.home> X-Stat-Signature: zma977s46nhpq8sjktpwjh1dy4s7117c X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 79BCC18003C Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=OSzfMYbM; spf=pass (imf16.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-HE-Tag: 1650664307-490369 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 Fri, Apr 22, 2022 at 04:47:44PM -0400, Steven Rostedt wrote: > Which is something you could do on top of seq_buf. Point being, you do not > need to re-implement printbuf, and I have not looked at the code, but > instead, implement printbuf on top of seq_buf, and extend seq_buf where > needed. Like trace_seq does, and the patches I have for seq_file would do. > It would leave the string processing and buffer space management to > seq_buf, as there's ways to see "oh, we need more space, let's allocate > more" and then increase the heap. That sounds like it could work. > I would be more willing to accept a printbuf, if it was built on top of > seq_buf. That is, you don't need to change all your user cases, you just > need to make printbuf an extension of seq_buf by using it underneath, like > trace_seq does. Then it would not be re-inventing the wheel, but just > building on top of it. Hmm... At first glance, redoing printbuf on top of seq_buf looks like it would save a pretty trivial amount of code - and my engineering taste these days leans more toward less layering if it's only slightly more code; I think I might like printbuf and seq_buf to stay separate things (and both of them are pretty small). But it's definitely not an unreasonable idea - I can try it out and see how it turns out. Would you have any objections to making some changes to seq_buf? - You've got size and len as size_t, I've got them as unsigned. Given that we need to be checking for overflow anyways for correctens, I like having them as u32s. - seq_buf->readpos - it looks like this is only used by seq_buf_to_user(), does it need to be in seq_buf? - in printbufs, I make sure the buffer is always nul-terminated - seems simplest, given that we need to make sure there's always room for the terminating nul anyways. A downside of having printbuf on top of seq_buf is that now we've got two apis that functions can output to - vs. if we modified printbuf by adding a flag for "this is an external buffer, don't reallocate it". That approach would be less code overall, for sure. Could I get you to look over printbuf and share your thoughts on the different approaches?