Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp221171imj; Wed, 13 Feb 2019 07:17:01 -0800 (PST) X-Google-Smtp-Source: AHgI3IY86ik+aaTXM9nD6JZuzuVwljBaiBc0dZrwPBCesKoW1x2rQSA3NCKjGSrNlrdCEzs58pxx X-Received: by 2002:a63:fe58:: with SMTP id x24mr899887pgj.255.1550071021264; Wed, 13 Feb 2019 07:17:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550071021; cv=none; d=google.com; s=arc-20160816; b=I5FcNKS1zoMvXk13ujAaaCUns2QSaP8VxdMxLEj7DGfuCXx81tag44nGI6G69HtCs1 olrWmuO9ooWd8CuEhXp+9W5hjlMgi4BKHutgkNSB8HbGc0UVbnUWSXXe9y6Fxk9REYye Co12PnNAuP3eCH39stwdxgAKaR27VtiUsveQsAX66Hip81XJkY76xq5mPaAnDjxsSFaf yxFTVQjNZnx1qAv5Fl9uehSyMWgVlAIduDAa/Bhykem3q834+FGR1YUId/AfSARDOVlB vaS1yStDyc3jbQxjFcaur1Uqg1kEzwxxMO6B2ojuQweGHU8sdqXkxSS/sczhqH2/OCr3 4/dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=xTjI2/Ajy37PZLMNl4cByPDP39U/IlvQwlM6P0/dBWo=; b=0lMDcoHFVoE+mkbD2pqgWZoezkKkK5Yqkxf17zVtfykbJXl3hMP+hK7hKkeknpJEcQ 6I4D1P1rME6FLQ1Wpdglt1l69mT/w9+RMXoubKCUm0fNFj2l9hZac9TBBperZk4j3OLS 7Dx6uNPAY8HEZkVhBRTYplU21D8P3uwrIqDn8G/giS0Dp5BR6X9cX3cG3E/xt9QCRo4s gMoG2enGNpW+GWVpsOWQPCTIoqjKX/M/p2iFdTldmY6ii2zfNcdd4EUTMXXjXH5ygEGu Tq8NbopuqQI0jnv4635WVJ1WTPex1/JrY0BpFu8MWDeFShCYD9Oy5XU5BhSdxmZokS6U GLlQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h186si776068pfb.73.2019.02.13.07.16.44; Wed, 13 Feb 2019 07:17:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392253AbfBMOb5 (ORCPT + 99 others); Wed, 13 Feb 2019 09:31:57 -0500 Received: from mail.kernel.org ([198.145.29.99]:39646 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726655AbfBMOb5 (ORCPT ); Wed, 13 Feb 2019 09:31:57 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (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 65C0B222B2; Wed, 13 Feb 2019 14:31:56 +0000 (UTC) Date: Wed, 13 Feb 2019 09:31:54 -0500 From: Steven Rostedt To: xiang xiao Cc: Petr Mladek , Sergey Senozhatsky , linux-kernel@vger.kernel.org, Xiang Xiao Subject: Re: [PATCH] printk: add KERN_NOTIME to skip the timestamp Message-ID: <20190213093154.7af84743@gandalf.local.home> In-Reply-To: References: <1549995065-27597-1-git-send-email-xiaoxiang@xiaomi.com> <20190212144606.4b7cf0f8@gandalf.local.home> <20190213084741.5512307a@gandalf.local.home> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 13 Feb 2019 22:00:04 +0800 xiang xiao wrote: > On Wed, Feb 13, 2019 at 9:47 PM Steven Rostedt wrote: > > > > On Wed, 13 Feb 2019 14:19:01 +0800 > > xiang xiao wrote: > > > > > On Wed, Feb 13, 2019 at 3:46 AM Steven Rostedt wrote: > > > > > > > > On Wed, 13 Feb 2019 02:11:05 +0800 > > > > Xiang Xiao wrote: > > > > > > > > > Because log may already add the timestamp sometime > > > > > > > > Can you be a bit more detailed on this. When and where does this > > > > happen? > > > > > > Here is my case: > > > 1.A small MCU(Cortex M4) in SoC run RTOS > > > 2.RTOS append timestamp to log for the accurate timing > > > 3.RTOS send log to Linux kernel when buffer exceed the threshold > > > 4.Kernel call printk to dump the received buffer > > > So I want that printk skip the timestamp here. > > > > > > > If anything, I would probably prefer that we export whether > > > > time is being printed, and have the caller not print time if printk is > > > > doing it already, than to add the complexity into printk itself. > > > > > > Actually, the timestamp of our initial implementation like your > > > suggestion come from printk, > > > but we found that timestamp from kernel isn't accurate as from RTOS > > > due the buffer and IPC. > > > > > > > If the timestamps are different, then you don't want to remove the > > printk one. Otherwise you are going to have a confusion between your > > added timestamp mixed in with the kernel's inaccurate timestamps. > > > > Here is a sample output with this patch: > [ 10.991426] virtio_rpmsg_bus virtio1: rpmsg host is online > [ 10.991443] remoteproc remoteproc1: registered virtio1 (type 7) > [ 10.991450] remoteproc remoteproc1: remote processor > f9210000.toppwr:sen-rproc is now up > [ 10.993715] virtio_rpmsg_bus virtio1: creating channel > rpmsg-ttySENSOR addr 0x1 > [ 10.994606] virtio_rpmsg_bus virtio1: creating channel rpmsg-ttyGPS addr 0x2 > [ 10.995236] virtio_rpmsg_bus virtio1: creating channel rpmsg-clk addr 0x3 > [ 10.995702] virtio_rpmsg_bus virtio1: creating channel rpmsg-syslog addr 0x4 > [ 10.996197] virtio_rpmsg_bus virtio1: creating channel rpmsg-rtc addr 0x5 > [ 10.997297] virtio_rpmsg_bus virtio1: creating channel rpmsg-hostfs addr 0x6 > [ 10.999842] virtio_rpmsg_bus virtio1: creating channel rpmsg-usrsock addr 0x7 > [ 0.007680] sensor: NuttX sensor 7.28 e3c2ecb Feb 12 2019 16:53:49 > arm song/banks > ^^^^^^^^^^^^^ > [ 11.918177] random: crng init done > [ 12.567362] e2fsck: e2fsck 1.42.9 (28-Dec-2013) > > Without this patch: > [ 10.991426] virtio_rpmsg_bus virtio1: rpmsg host is online > [ 10.991443] remoteproc remoteproc1: registered virtio1 (type 7) > [ 10.991450] remoteproc remoteproc1: remote processor > f9210000.toppwr:sen-rproc is now up > [ 10.993715] virtio_rpmsg_bus virtio1: creating channel > rpmsg-ttySENSOR addr 0x1 > [ 10.994606] virtio_rpmsg_bus virtio1: creating channel rpmsg-ttyGPS addr 0x2 > [ 10.995236] virtio_rpmsg_bus virtio1: creating channel rpmsg-clk addr 0x3 > [ 10.995702] virtio_rpmsg_bus virtio1: creating channel rpmsg-syslog addr 0x4 > [ 10.996197] virtio_rpmsg_bus virtio1: creating channel rpmsg-rtc addr 0x5 > [ 10.997297] virtio_rpmsg_bus virtio1: creating channel rpmsg-hostfs addr 0x6 > [ 10.999842] virtio_rpmsg_bus virtio1: creating channel rpmsg-usrsock addr 0x7 > [ 11.105345][ 0.007680] sensor: NuttX sensor 7.28 e3c2ecb Feb 12 > 2019 16:53:49 arm song/banks > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > [ 11.918177] random: crng init done > [ 12.567362] e2fsck: e2fsck 1.42.9 (28-Dec-2013) > > Which one do you think better? Honestly, the one without the patch. Seriously, it also makes it easy to see where that message happened with respect to the other printks. With your patch, we would have no idea, and if I was a normal user, unaware of this patch, I would probably submit a bug report claiming that something is wrong with the timestamps. -- Steve