Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp207584imj; Wed, 13 Feb 2019 07:05:44 -0800 (PST) X-Google-Smtp-Source: AHgI3Ibo9LQ1tNwzVkDnswuIbne+/KQoBKH/FgQVYia0dXF0aGFvFmGCVvv7sg2oYbdquUQ0A+aN X-Received: by 2002:a63:61c9:: with SMTP id v192mr914818pgb.120.1550070344529; Wed, 13 Feb 2019 07:05:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550070344; cv=none; d=google.com; s=arc-20160816; b=Pz/oPQJ6CviFZ8GNSWc2uAWNwsEEP1CFAeG58xnLdAj82JAS47HQIyjIYCvOUl5mQd 5z1FCTrtzKz9VcE3we/akmmcwsxcjxc9So4TuOYR+j/D6TCdL6D2+FxXX0oHobll6vpo 1XrdBb5URgNNjdHoPXMuvY8FS9NAq/Eb6HmYxHBOYfQTX/9hdGll91wo/IFV+evW2EPH j174LwqPZABuAMjxJFiaYM4ZHqEOjIg9hHm5KjtRP8yweV/oEylM2w5VTK8XiHa11/X7 Afpmz2y9R5I2UcbxHDJEhzOP+UJ6ChcPqsdZR/o9P3ci5IMYRMqvYMPrnDP+v+Q/6776 dLXA== 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=ZA2e+0Jn0MW0xVjI/Iz6k2xv+MkEufgoiRVW1VIiGkQ=; b=S7bh4D3kLf2nCu1kfhogvB2oYSdJBs7d90eMB4FxUMv1FMl7FExSM6eWQ1OPEumZx0 H8rCyRSPLwvoYuCvh8VotB7xR3MedjZtm661OMXQDHCbQDAldmhfPrTef2JNnRTRFZTe 5fLomFxmZ89YTJuYF8zzVLigaBuDPxtmgODJi6xZVBKtH/v1bUgJ8jhz6eCnjjHzdjZ5 WCvVBtqb2bY94vz/pDzUgp9X+J9pCFdB3gaShyVp8dTvKCzwc4m4TAHjfA+V59BNh5kY /GithkEwZ6KCOS8el5YsRtkyH8au76tJgJK609FwakBlJ7T+jq4xl6eV/PLI4wrGJw2E pJ4w== 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 s136si14757313pgs.277.2019.02.13.07.05.26; Wed, 13 Feb 2019 07:05:44 -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 S1732001AbfBMNro (ORCPT + 99 others); Wed, 13 Feb 2019 08:47:44 -0500 Received: from mail.kernel.org ([198.145.29.99]:59848 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730351AbfBMNrn (ORCPT ); Wed, 13 Feb 2019 08:47:43 -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 23985218D3; Wed, 13 Feb 2019 13:47:43 +0000 (UTC) Date: Wed, 13 Feb 2019 08:47:41 -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: <20190213084741.5512307a@gandalf.local.home> In-Reply-To: References: <1549995065-27597-1-git-send-email-xiaoxiang@xiaomi.com> <20190212144606.4b7cf0f8@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 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. -- Steve