Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp173459imj; Wed, 13 Feb 2019 06:33:50 -0800 (PST) X-Google-Smtp-Source: AHgI3IbRIIHvaZ3Mk0daL8bQyzegH6OxM/t+9yQuEFw3ApYfPuP714/L9M/YPBQI/zHymyGfFgvL X-Received: by 2002:a17:902:b485:: with SMTP id y5mr839896plr.298.1550068430290; Wed, 13 Feb 2019 06:33:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550068430; cv=none; d=google.com; s=arc-20160816; b=YlReCw4Yw+YMvomgFW2oxfepheuX5NeAEcfG0GJct51kP5RAc+4vppJ6nxBR+QQJXv 5EwXr8/Yzogo+P/tO3itCH7oI9d2miDd8ZYeedp/BNK1btBJiqByGNfVhj/pAzDdNVzb 8uMxGJZ93iqvI4PXu39S7+gUQW/PNiYiOl9x67s+gAkCqBK115JHA7GZzDWeQj1AoMjd nFClRMG1pN+pBFA1JeiJk0O0K0ycYHjGUcB+fAAbM94k7Zp9EK6NkY5FfnOflGwmpb4S 7cBILYZRkBWs83kp/CQ3IHZVWMcweLO21w2rGHHIcs9zn33FS4nPhYRtRPL7CfISUPZZ dpUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=a3eNmRNOvcjGHXFGy+HFN8XlXVUnjg/xjTTNPBbVZcA=; b=QnshNvqtDn5ng/1Yh8b0FXY7ih5027FuxXlWU0gquLFw3u5HLbsS4Ed3kgx5AVpe+L g3NG9cSF+JaggxR8cX7MwVGq2L4ebHs9aUiX+Ry3InPn+00HmgC1dpfSErHhhCWRjWWI apwFJrS0E9XHGDorOinJi1wXeQHm50jkjNT5JSM89kpRIhJqZ5VLc51EfQ48/btgGXYV ZJ4xqAP6Mv+flNkuwQuci/+agPbPwYowHXIZSeGbLBe8hLLlxwFjSGI+Hu0Dvbv5j8iH fRyi2l988xIZfV6yzLJG6YiRqElOPOJTcb7O/+IT5f11cpGS6SQMlNEVVyS4hfDWVZpp YvnQ== 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 h3si15051806pgi.391.2019.02.13.06.33.33; Wed, 13 Feb 2019 06:33:50 -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 S2390368AbfBMNTR (ORCPT + 99 others); Wed, 13 Feb 2019 08:19:17 -0500 Received: from mx2.suse.de ([195.135.220.15]:39010 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730377AbfBMNTO (ORCPT ); Wed, 13 Feb 2019 08:19:14 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D0319B03B; Wed, 13 Feb 2019 13:19:12 +0000 (UTC) Date: Wed, 13 Feb 2019 14:19:12 +0100 From: Petr Mladek To: xiang xiao Cc: Steven Rostedt , Sergey Senozhatsky , linux-kernel@vger.kernel.org, Xiang Xiao Subject: Re: [PATCH] printk: add KERN_NOTIME to skip the timestamp Message-ID: <20190213131912.4w3fonbgwjathpyp@pathway.suse.cz> References: <1549995065-27597-1-git-send-email-xiaoxiang@xiaomi.com> <20190212144606.4b7cf0f8@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2019-02-13 14:19:01, 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 What do you exactly mean by the threshold, please? Does it mean that you use the kernel buffer when there are too many messages and they do not fit into the MCU local buffer? How exactly the kernel gets the messages, please? Via a kernel driver or from userspace (via /dev/kmsg)? > 4.Kernel call printk to dump the received buffer > So I want that printk skip the timestamp here. If the messages are printed by a kernel driver then a better solution would be to create a printk() API where you could pass the time stamp as a parameter. The aim is to store the precise time stamp in ts_nsec, struct printk_log. Then it will get handled correctly by any output, e.g. consoles, syslog, /dev/kmsg. There are several problems with your approach: 1. The time stamp is still duplicated in the output via /dev/kmsg, see msg_print_ext_header(). We could not change this because the time stamp is part of the format. Any change could break userspace (systemd). 2. The time stamp stays part of the message: + It might have different format than the normal time stamp. Therefore it might be hard to filter + dmesg might be unable to parse it and show in the other formats. + Kernel-5.1 will allow to print information about the caller. It is supposed to be between the time stamp and the message text, see http://lkml.kernel.org/r/93f19e57-5051-c67d-9af4-b17624062d44@i-love.sakura.ne.jp Best Regards, Petr