From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger Date: Thu, 01 Aug 2019 14:14:46 -0700 Message-ID: <20190801211447.6D3D7206A2@mail.kernel.org> References: <20190716175021.9CA412173C@mail.kernel.org> <20190719000834.GA3228@google.com> <20190722200347.261D3218C9@mail.kernel.org> <20190722235411.06C1320840@mail.kernel.org> <20190724073125.xyzfywctrcvg6fmh@pathway.suse.cz> <20190726083148.d4gf57w2nt5k7t6n@pathway.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Brendan Higgins Cc: devicetree , Peter Zijlstra , Amir Goldstein , dri-devel , Sasha Levin , Masahiro Yamada , Michael Ellerman , "open list:KERNEL SELFTEST FRAMEWORK" , shuah , Rob Herring , linux-nvdimm , Timothy Bird , Frank Rowand , "open list:DOCUMENTATION" , Knut Omang , Kieran Bingham , wfg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org, Joel Stanley , David Rientjes , Kevin Hilman , Dan Carpenter , Petr Mladek List-Id: dri-devel@lists.freedesktop.org Quoting Brendan Higgins (2019-08-01 11:59:57) > On Thu, Aug 1, 2019 at 11:55 AM Brendan Higgins > wrote: > > > > On Fri, Jul 26, 2019 at 1:31 AM Petr Mladek wrote: > > > > > To be honest I do not fully understand KUnit design. I am not > > > completely sure how the tested code is isolated from the running > > > system. Namely, I do not know if the tested code shares > > > the same locks with the system running the test. > > > > No worries, I don't expect printk to be the hang up in those cases. It > > sounds like KUnit has a long way to evolve before printk is going to > > be a limitation. > > So Stephen, what do you think? > > Do you want me to go forward with the new kunit_assert API wrapping > the string_stream as I have it now? Would you prefer to punt this to a > later patch? Or would you prefer something else? > I like the struct based approach. If anything, it can be adjusted to make the code throw some records into a spinlock later on and delay the formatting of the assertion if need be. Can you resend with that approach? I don't think I'll have any more comments after that.