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 54B4EC433F5 for ; Fri, 22 Apr 2022 19:30:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E5F86B0073; Fri, 22 Apr 2022 15:30:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 895156B0074; Fri, 22 Apr 2022 15:30:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 735966B0075; Fri, 22 Apr 2022 15:30:19 -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 6517A6B0073 for ; Fri, 22 Apr 2022 15:30:19 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 44BDD60F41 for ; Fri, 22 Apr 2022 19:30:19 +0000 (UTC) X-FDA: 79385506158.30.7DA092F Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf14.hostedemail.com (Postfix) with ESMTP id 0401F10002F for ; Fri, 22 Apr 2022 19:30:17 +0000 (UTC) Received: by mail-qk1-f170.google.com with SMTP id e128so6524938qkd.7 for ; Fri, 22 Apr 2022 12:30:18 -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=uaw3jQI0O7lfuasFDAU1iMGalKK6DqU9oePbaLb6Lpo=; b=jSBuMPPxD+TRF+uvoRePfqLx62akhHX4yKi60akXL8zvbnY79lrrPOv9UdoTTN6G03 Z3Z6xJWsC44e2+sH601gYFYQRahbzOlLTXCLTR7DpvXVU7hdwors1gULh5GCqc6Ai1Xp xH2iybM481G86VuD9jW/RRoA7ua81x00JPulz+mRHkD1xdubsNPwLiT4kmVqxX7Rwm0+ bWXe1pdPRZ/WrNqxSXBKagepCTNXYFpKudiprDzf06IGDaereV2WJ1I+PhmjNJcvMCER qqEMvrIVug0YQphPqXtbOOyBwQi0iB/t+Dyq8nT6ygBsRs4PscXLhPGC/9Je3uLiCX0R juyw== 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=uaw3jQI0O7lfuasFDAU1iMGalKK6DqU9oePbaLb6Lpo=; b=4GBroP0QzKACO9Lz6veX3MXd+flvVhazvE8zS3C5IYSzVYRuzHhQ6B5hN6CfiEMmZZ XqgYkqs3CCJ1FCqP5QifJk44xZ+MmGuOlFiGF54FcRTmm0eAsDVXq5mIZVc8b8Ef+PXP t8f/VM4TCoIuMKIfItZv8hcTr7XURnC4ZlHQfgThwxPkefvg3E1hwYrsSeBHnChlazky eoS7NX8yvn3F8ZXLLWsfKYKnSN44o+TJfrd3WJiQ2eqC+F9oESqrLuGarKDJDl+2Y92m rySkWcpcsSkPI/KUK0pzRfkOQdPsbp1Mh5dq34CES72pvHyTCEfISzsj6gGD7Bs83MuT bEuQ== X-Gm-Message-State: AOAM532heLiB6qOYmBhiHh5klDKqp06qxEzIcTfFH6DGB0ldc/sCX7gd Nn3vIcricVsdJCHx6Q6hug== X-Google-Smtp-Source: ABdhPJwRNFuGFN5zUpqH2tATD7eZCTHBc5A5LvoxXTRq8ugddn1nAMCTX2JWMw8ITL691waO11UeTQ== X-Received: by 2002:a37:6902:0:b0:606:853:fe50 with SMTP id e2-20020a376902000000b006060853fe50mr3597093qkc.751.1650655818042; Fri, 22 Apr 2022 12:30:18 -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 bl14-20020a05620a1a8e00b0069e622e593esm1219789qkb.95.2022.04.22.12.30.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 12:30:17 -0700 (PDT) Date: Fri, 22 Apr 2022 15:30:15 -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: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220422113736.460058cc@gandalf.local.home> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 0401F10002F X-Stat-Signature: fiw5w6hg9ub9tbsxu1hunk3uz6qic6es Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=jSBuMPPx; spf=pass (imf14.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1650655817-462712 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Steve! On Fri, Apr 22, 2022 at 11:37:36AM -0400, Steven Rostedt wrote: > On Fri, 22 Apr 2022 01:40:15 -0400 > Kent Overstreet wrote: > > > So I'm honestly not super eager to start modifying tricky arch code that I can't > > test, and digging into what looked like non trivial interactions between the way > > the traceing code using seq_buf (naturally, given that's where it originates). > > Yes, seq_buf came from the tracing system but was to be used in a more > broader way. I had originally pushed trace_seq into the lib directory, but > Andrew Morton said it was too specific to tracing. Thus, I gutted the > generic parts out of it and created seq_buf, which looks to be something > that you could use. I had patches to convert seq_file to it, but ran out of > time. I probably can pull them out of the closet and start that again. > > > > > Now yes, I _could_ do a wholesale conversion of seq_buf to printbuf and delete > > that code, but doing that job right, to be confident that I'm not introducing > > bugs, is going to take more time than I really want to invest right now. I > > really don't like to play fast and loose with that stuff. > > I would be happy to work with you to convert to seq_buf. If there's > something missing from it, I can help you change it so that it doesn't > cause any regressions with the tracing subsystem. > > 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 :) 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 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 :)