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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2159AC433F5 for ; Wed, 4 May 2022 09:46:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347732AbiEDJuX (ORCPT ); Wed, 4 May 2022 05:50:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347727AbiEDJuN (ORCPT ); Wed, 4 May 2022 05:50:13 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C445726540 for ; Wed, 4 May 2022 02:46:38 -0700 (PDT) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 4CF78210DC; Wed, 4 May 2022 09:46:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1651657597; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=f2BU3+t5DYqkYThY0d1gO61pXwUsjhrMxVTtLHPwDPI=; b=DNW0smbOABig+ojoNBZ4DbJ6aEVK89nHBYWenqKldvaZyMeTKvPDNBJj/h5udOUsgAtqDP 6YAU77GyISTlPJEktcS2MlvU9T+TVOPYGI112xJfidWHrRifGr2Y16wD2VFoiWSPI+nig3 CfcoYgR6RMcExiGJfAaOkodK3ZSMqmY= Received: from suse.cz (pathway.suse.cz [10.100.12.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id EC0192C141; Wed, 4 May 2022 09:46:36 +0000 (UTC) Date: Wed, 4 May 2022 11:46:36 +0200 From: Petr Mladek To: John Ogness Cc: Marco Elver , Sergey Senozhatsky , Steven Rostedt , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Thomas Gleixner , Johannes Berg , Alexander Potapenko , Dmitry Vyukov , Naresh Kamboju , Linux Kernel Functional Testing Subject: Re: [PATCH -printk] printk, tracing: fix console tracepoint Message-ID: <20220504094636.GA8069@pathway.suse.cz> References: <20220503073844.4148944-1-elver@google.com> <87r15ae8d7.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r15ae8d7.fsf@jogness.linutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 2022-05-03 21:20:44, John Ogness wrote: > On 2022-05-03, Marco Elver wrote: > > One notable difference is that by moving tracing into printk_sprint(), > > the 'text' will no longer include the "header" (loglevel and timestamp), > > but only the raw message. Arguably this is less of a problem now that > > the console tracepoint happens on the printk() call and isn't delayed. > > Another slight difference is that messages composed of LOG_CONT pieces > will trigger the tracepoint for each individual piece and _never_ as a > complete line. > > It was never guaranteed that all LOG_CONT pieces make it into the final > printed line anyway, but with this change it will be guaranteed that > they are always handled separately. > > I am OK with this change, but like Steven, I agree the the users of that > tracepoint need to chime in. My feeling is that the feature is not used much. Otherwise people would complain that it was asynchronous and hard to use. I mean that the printk() messages appeared in the trace log asynchronously. So it required some post processing to correctly sort them against other tracing messages. The same result can be achieved by processing printk log buffer, dmesg.log, journalctl. I guess that we will only find the answer when we push the change into linux-next and mainline. I am going to do so. Reviewed-by: Petr Mladek Best Regards, Petr