Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp209208imj; Wed, 13 Feb 2019 07:07:01 -0800 (PST) X-Google-Smtp-Source: AHgI3IZos4BuREoskza/E6klee8KV6CwxrdkddDIFd2+9Qsz2xu3dilStVuxifqiiffqsE+RMSIk X-Received: by 2002:a17:902:bd82:: with SMTP id q2mr1008892pls.156.1550070421269; Wed, 13 Feb 2019 07:07:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550070421; cv=none; d=google.com; s=arc-20160816; b=W9jpUEM6e9OcQUAtKoAxr/Ai8lzNRBxmBQD/WkByVpTOU0TBn7OmQyZ5ti8ehpXzlB W0e92WYirbruXGXDa1mQ9GGUnsRACJx/ng6pA3CRwiW3inW4pdHjBPbpiA67cYHdbiV0 mdlQBfK3LMiRf10DL2vWxQT+NZ1uFktUsZgXiWF5s2kvIRWMynCmwoxEvkPCk0/9A5Pg MAvI2PG+WvvMBLweOtiEa7uyrNDu/4QrElTcWbGgylc5ofiui2dzKDF0a5CHtZNnu31v 4GNDJn2qFGw2K0qa8he0blaTtJ+oBl1y7q0i/jnqs71/O+SQpDDuf7L+sN3eLKQoKEl+ wEVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=sZzUxIwwVmyGRTq67o/RmvEGq558xPaPNzxNRIq1QbU=; b=AZS2Mze2LdLZr5EKFSm6tYFKOd1DsCoN9Lv5wOU8dU+7bJ+khrkBi0P2Kuqy5AmLGj dWsC5YNJPctZzOCu4qivTfyLhsPEgdMItiQWCoEHYt+r9S8iT5BkPMdYfODiFJEe5Bvo r5NwH0l8ab5pV4RLj2xBhYWLai836AhhHSv/pRQZEuFZLkP5bJrKY5AL6OPkxZmCBenO qBnLHj8RsKmEYnnA6m1SaqT99NAt29T5MZTJz9eb3c4K5kmMtqzreXpGH5SU9R3H1Dp7 NUCheZveVJhmnBeeIfZ8NyNYW8LiN13Mm5qUNDXpyJqopxPrCcuZw1ZCsrha4lCRYWnw 6ESw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=sKsEihHB; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a90si8038238plc.314.2019.02.13.07.06.44; Wed, 13 Feb 2019 07:07: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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=sKsEihHB; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732805AbfBMNtw (ORCPT + 99 others); Wed, 13 Feb 2019 08:49:52 -0500 Received: from mail-qk1-f193.google.com ([209.85.222.193]:38826 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727452AbfBMNtv (ORCPT ); Wed, 13 Feb 2019 08:49:51 -0500 Received: by mail-qk1-f193.google.com with SMTP id p15so1344090qkl.5 for ; Wed, 13 Feb 2019 05:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sZzUxIwwVmyGRTq67o/RmvEGq558xPaPNzxNRIq1QbU=; b=sKsEihHBuVPCradf+BqHQ5EgQt1TWsSdA2OJMuA2r/FuJDQh/DAlD5hmq9oOfVhf2/ YsOKbcCfMgHfs0w5XS6AxFaIF64yhTe6KOYyqhiHhCCXCoQtqZqDKkoCiurNthEeohUO At13S8c6qfyiNmLoDe14cC0K1JoRWaacp16VTm0ZdiuTBymZxp/sDQoZXHwXlHzGIudB lQroSDyVuPUu6qps2PcgDshiJcK4P7UxV1p2cEtvWkYSo2FZt27yIsWhmyiEFyYWUA19 8GCmDMT4LtDNsGm2MH9Z4eV0UhittrufxEvAURQrT9uromMuCWnpphVdW1qMOde0GXXU orJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sZzUxIwwVmyGRTq67o/RmvEGq558xPaPNzxNRIq1QbU=; b=e0wqKDnMG/11uHtyDDgxbWxqQIgnJyxKp7UlITeAbH2RadOcLteRIxMUkyFRwPEp8e 6I+h8R/UquW3TwrNyq357OAXVQfLYbFkrT1qoArgNyKZoML7qetA19CDkPaH24yJ6le8 dXz62q6IGXbGhkibdwdUuCCmZ45V13bVw89SfJTpTxy3H3HBLFypF+dFHy8vjeQZpY6j sJ0/2h/v3venxfOCweL2l/zY0HeoOFeaWAIbk+EP/cAFeg/rh6W6YBaIZJAj8T9FxvlK 97caS98G/1bAs6KzXQ19XdO3gNr/rrYV2rOj/YJ5AgQVYkDMLXRyaSiL5MvMV9t5XDfo 4fCg== X-Gm-Message-State: AHQUAuacs5d2WbyKJo5w04YJBUon8dCAjJB5HXajq+dAsTViLwHq01tv sLHbP6aAwACdCpWJBrCMsysB9k5wUsrGT389OlZC6na4kPs= X-Received: by 2002:ae9:ed12:: with SMTP id c18mr442986qkg.39.1550065790242; Wed, 13 Feb 2019 05:49:50 -0800 (PST) MIME-Version: 1.0 References: <1549995065-27597-1-git-send-email-xiaoxiang@xiaomi.com> <20190212144606.4b7cf0f8@gandalf.local.home> <20190213131912.4w3fonbgwjathpyp@pathway.suse.cz> In-Reply-To: <20190213131912.4w3fonbgwjathpyp@pathway.suse.cz> From: xiang xiao Date: Wed, 13 Feb 2019 21:49:30 +0800 Message-ID: Subject: Re: [PATCH] printk: add KERN_NOTIME to skip the timestamp To: Petr Mladek Cc: Steven Rostedt , Sergey Senozhatsky , linux-kernel@vger.kernel.org, Xiang Xiao Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 13, 2019 at 9:19 PM Petr Mladek wrote: > > 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? The current algorithm is: 1.the free space is less than 25% or 2.the idle time is large than 100ms > 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? The buffering just happen in MCU side, kernel don't do any buffering except waiting for '\n' before printk. > > How exactly the kernel gets the messages, please? > Via a kernel driver or from userspace (via /dev/kmsg)? > It's a kernel rpmsg driver: https://github.com/thesofproject/linux/pull/177/commits/a0b7009fede5552dc98733f2996a8140bff62455 > > > 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. Yes, this is a better approach and could fix all issues you list below. > > 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