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 X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B683C7618F for ; Mon, 22 Jul 2019 23:54:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 43BEC217F9 for ; Mon, 22 Jul 2019 23:54:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563839656; bh=7riE0sVQmQS5QgS4pP9ptPUvfmyCxgbuxcUzFNIX2L8=; h=In-Reply-To:References:Subject:To:Cc:From:Date:List-ID:From; b=2KtckuScC/fsfjwVtGelOn2nqqTnpKIj4AvtnI8QiejskwgcBrZ49sH0VD92qCFP/ jxOFEk0POYatSUD4gjWjSKAqg393wrfp+4gQy5uChPzVeEW8jEYvdOw0iq9Bixsk1i diTKydfkUOgxjk7rVNWCDX4bawGd6S5sZs2o2tf0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387473AbfGVXyN (ORCPT ); Mon, 22 Jul 2019 19:54:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:47124 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731007AbfGVXyM (ORCPT ); Mon, 22 Jul 2019 19:54:12 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 06C1320840; Mon, 22 Jul 2019 23:54:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563839651; bh=7riE0sVQmQS5QgS4pP9ptPUvfmyCxgbuxcUzFNIX2L8=; h=In-Reply-To:References:Subject:To:Cc:From:Date:From; b=lMfzRRCskgjYJCyPlokQPKY6jX+VpgCrEwPkMIQvRxf8iOB5wgrS9PjXaN0wjtfWh RiuaqfDlvSUHC1e16Pk0GMsnB1H5f28N5075BUdTFeSOe4/ZlQbTkjJF0oMcqI6dyP T+b1BFHi89keU/CNeTzd05/B7YC7Rqku9pnyKVeY= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20190712081744.87097-1-brendanhiggins@google.com> <20190716175021.9CA412173C@mail.kernel.org> <20190718175024.C3EC421019@mail.kernel.org> <20190719000834.GA3228@google.com> <20190722200347.261D3218C9@mail.kernel.org> Subject: Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger To: Brendan Higgins Cc: Frank Rowand , Greg KH , Josh Poimboeuf , Kees Cook , Kieran Bingham , Luis Chamberlain , Peter Zijlstra , Rob Herring , shuah , Theodore Ts'o , Masahiro Yamada , devicetree , dri-devel , kunit-dev@googlegroups.com, "open list:DOCUMENTATION" , linux-fsdevel@vger.kernel.org, linux-kbuild , Linux Kernel Mailing List , "open list:KERNEL SELFTEST FRAMEWORK" , linux-nvdimm , linux-um@lists.infradead.org, Sasha Levin , "Bird, Timothy" , Amir Goldstein , Dan Carpenter , Daniel Vetter , Jeff Dike , Joel Stanley , Julia Lawall , Kevin Hilman , Knut Omang , Logan Gunthorpe , Michael Ellerman , Petr Mladek , Randy Dunlap , Richard Weinberger , David Rientjes , Steven Rostedt , wfg@linux.intel.com From: Stephen Boyd User-Agent: alot/0.8.1 Date: Mon, 22 Jul 2019 16:54:10 -0700 Message-Id: <20190722235411.06C1320840@mail.kernel.org> Sender: linux-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org Quoting Brendan Higgins (2019-07-22 15:30:49) > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd wrote: > > > > > > What's the calling context of the assertions and expectations? I still > > don't like the fact that string stream needs to allocate buffers and > > throw them into a list somewhere because the calling context matters > > there. >=20 > The calling context is the same as before, which is anywhere. Ok. That's concerning then. >=20 > > I'd prefer we just wrote directly to the console/log via printk > > instead. That way things are simple because we use the existing > > buffering path of printk, but maybe there's some benefit to the string > > stream that I don't see? Right now it looks like it builds a string and > > then dumps it to printk so I'm sort of lost what the benefit is over > > just writing directly with printk. >=20 > It's just buffering it so the whole string gets printed uninterrupted. > If we were to print out piecemeal to printk, couldn't we have another > call to printk come in causing it to garble the KUnit message we are > in the middle of printing? Yes, printing piecemeal by calling printk many times could lead to interleaving of messages if something else comes in such as an interrupt printing something. Printk has some support to hold "records" but I'm not sure how that would work here because KERN_CONT talks about only being used early on in boot code. I haven't looked at printk in detail though so maybe I'm all wrong and KERN_CONT just works? Can printk be called once with whatever is in the struct? Otherwise if this is about making printk into a structured log then maybe printk isn't the proper solution anyway. Maybe a dev interface should be used instead that can handle starting and stopping tests (via ioctl) in addition to reading test results, records, etc. with read() and a clearing of the records. Then the seqfile API works naturally. All of this is a bit premature, but it looks like you're going down the path of making something akin to ftrace that stores binary formatted assertion/expectation records in a lockless ring buffer that then formats those records when the user asks for them. I can imagine someone wanting to write unit tests that check conditions from a simulated hardirq context via irq works (a driver mock framework?), so this doesn't seem far off.