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 C9A56C433F5 for ; Fri, 22 Apr 2022 19:39:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 383FE6B0073; Fri, 22 Apr 2022 15:39:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 30D846B0074; Fri, 22 Apr 2022 15:39:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BA526B0075; Fri, 22 Apr 2022 15:39:22 -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 057426B0073 for ; Fri, 22 Apr 2022 15:39:22 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D0760F8F for ; Fri, 22 Apr 2022 19:39:21 +0000 (UTC) X-FDA: 79385528922.11.B0F8F66 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 8E5E01C002A for ; Fri, 22 Apr 2022 19:39:19 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 838C26198A; Fri, 22 Apr 2022 19:39:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1B01C385A4; Fri, 22 Apr 2022 19:39:18 +0000 (UTC) Date: Fri, 22 Apr 2022 15:39:16 -0400 From: Steven Rostedt To: Kent Overstreet 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: <20220422153916.7ebf20c3@gandalf.local.home> In-Reply-To: <20220422193015.2rs2wvqwdlczreh3@moria.home.lan> References: <20220421234837.3629927-1-kent.overstreet@gmail.com> <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> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 8E5E01C002A Authentication-Results: imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of "SRS0=ohlw=VA=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=ohlw=VA=goodmis.org=rostedt@kernel.org"; dmarc=none X-Rspam-User: X-Stat-Signature: 8dz3xeqfz65wcxi77465ckro44t44x87 X-HE-Tag: 1650656359-540175 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, 22 Apr 2022 15:30:15 -0400 Kent Overstreet wrote: > > This is how open source programming is suppose to work ;-) > > Is it though? :) > > One of the things I've been meaning to talk more about, that > came out of a recent Rust discussion, is that we in the kernel community could > really do a better job with how we interact with the outside world, particularly > with regards to the sharing of code. > > The point was made to me when another long standing kernel dev was complaining > about Facebook being a large, insular, difficult to work with organization, that > likes to pretend it is the center of the universe and not bend to the outside > world, while doing the exact same thing with respect to new concerns brought by > the Rust community. The irony was illuminating :) I do not consider Facebook an open source company. One reason I turned them down. > > The reason I bring that up is that in this case, printbuf is the more evolved, > more widely used implementation, and you're asking me to discard it so the > kernel can stick with its more primitive, less widely used implementation. > > $ git grep -w seq_buf|wc -l > 86 > > $ git grep -w printbuf|wc -l > 366 $ git grep printbuf drivers/media/i2c/ccs/ccs-reg-access.c: char printbuf[(MAX_WRITE_LEN << 1) + drivers/media/i2c/ccs/ccs-reg-access.c: bin2hex(printbuf, regdata, msg.len); drivers/media/i2c/ccs/ccs-reg-access.c: regs->addr + j, printbuf); I don't see it. And by your notion: $ git grep trace_seq | wc -l 1680 Thus we all should be using trace_seq! > > So, going to have to push back on that one :) > > Printbufs aren't new code; everything in them is there because I've found it > valuable, which is why I decided to try promoting them to the kernel proper (and > more importantly, the idea of a standard way to pretty-print anything). > > I'm happy to discuss the merits of the code more, and try to convince you why > you'll like them :) I'd like to know more to why seq_buf is not good for you. And just telling me that you never seriously tried to make it work because you were afraid of causing tracing regressions without ever asking the tracing maintainer is not going to cut it. -- Steve