Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp1910330ybd; Sun, 23 Jun 2019 19:52:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqw8w+mkr+9gX8sqB0X1TfeZckVr21guWxwBdp6BqN4WfX1bG3lY4nJAryXw1FWq60Z+QRpR X-Received: by 2002:a17:90a:aa81:: with SMTP id l1mr20958878pjq.55.1561344768699; Sun, 23 Jun 2019 19:52:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561344768; cv=none; d=google.com; s=arc-20160816; b=lIFvr5B0KE4ncNRz0opJ0+qBEjkcA4rBi9fi/dg4n7fCKusmT0I2CMN7iPDiuomtOp RECsPpv5fSBObXtaYEtzQ56s/HaD9WmRyUoUk0zP0WhKCmW/IRytn1bvyenxlvaAtzI3 NSqtRYAzeQ+xp5TZViqiBaWHbES8MPIakvPX5E4fBSmhnbs3XpKCuUtNjkaje5LVuye5 M5dEAGKP9hK9EnstDmzBaxxFkV6n4PYSmKa4wOeViy2yzcowv+qVazKJsp/mgayqSUnj JvrqUXLJTkoPzu8m7jImaZqcLJSTX/OnwNbB93YRqZnrGD6LXxeVS+kxgTpqJp6D549t jO7w== 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 :dkim-signature; bh=EFX3X/3C5Z2NYpQEgP5bHHhkTbrRTmzsJ6P//2tJCvA=; b=xB5U+i2oU7bx2EWyxUFMib+7ZQrybdtB8eji6HnezXvsb8MIoKComFCEvIex1kheyz CGCbNBLPx0TTjZyWRZh3h/gHkfn0ok6nW4mwa4WVdsy8p5A1/U/bv3sEV7nWWAlHeMCX nt6pAx56kuJ7Gg47MJ21FiS8UOJ2yeLDAJxxI7h3d8r8bXJhb3KM9OIuNtnfdJ116a3O s5dGLNLWRCZ/6N6j9HyumXA6NtZ8ZwgAwQhpTkNeh3tDRJ1tRz8SVqMEp6qOF1uAJDZJ MAnwKqhAtEj7W+fJNAU4NdisS53Ydlpt1+kuiL9Lp3AQSYm16uV5Fp4ElQQt45wF8W5H QAmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=LpVN7Q7f; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m37si8911033pgl.592.2019.06.23.19.52.32; Sun, 23 Jun 2019 19:52:48 -0700 (PDT) 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=@kernel.org header.s=default header.b=LpVN7Q7f; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727269AbfFXCw3 (ORCPT + 99 others); Sun, 23 Jun 2019 22:52:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:54522 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726307AbfFXCw2 (ORCPT ); Sun, 23 Jun 2019 22:52:28 -0400 Received: from devnote2 (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (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 710092073F; Mon, 24 Jun 2019 02:52:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1561344747; bh=VkbMuwCphYI8uGxaBCG//nLfz474AdAA5lslPezgjig=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=LpVN7Q7fNPad8f+qFoOFbk6qmlnDc8XgshQ0IbiMqwpFxfk2BQkXR1L6FyLOW1uvQ h8pr/r6CcHfCjsNLufOFWevv/W+ax1IGs3P2tn9jhZ1FlEc3MFyvkG8qrwTXFPhJjA swCA6fHeB8ywCohpHL6HoL58bNdtN/tmKWfUwjmM= Date: Mon, 24 Jun 2019 11:52:23 +0900 From: Masami Hiramatsu To: Frank Rowand Cc: Steven Rostedt , Rob Herring , Tom Zanussi , Ingo Molnar , Namhyung Kim , Jiri Olsa , Arnaldo Carvalho de Melo , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [RFC PATCH 00/11] tracing: of: Boot time tracing using devicetree Message-Id: <20190624115223.db1e53549a15c6548bfa1fa1@kernel.org> In-Reply-To: References: <156113387975.28344.16009584175308192243.stgit@devnote2> X-Mailer: Sylpheed 3.5.1 (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 Hi Frank, Thank you for your comment! On Sun, 23 Jun 2019 12:58:45 -0700 Frank Rowand wrote: > Hi Masami, > > On 6/21/19 9:18 AM, Masami Hiramatsu wrote: > > Hi, > > > > Here is an RFC series of patches to add boot-time tracing using > > devicetree. > > > > Currently, kernel support boot-time tracing using kernel command-line > > parameters. But that is very limited because of limited expressions > > and limited length of command line. Recently, useful features like > > histogram, synthetic events, etc. are being added to ftrace, but it is > > clear that we can not expand command-line options to support these > > features. > > "it is clear that we can not expand command-line options" needs a fuller > explanation. And maybe further exploration. Indeed. As an example of tracing settings in the first mail, even for simple use-case, the trace command is long and complicated. I think it is hard to express that as 1-liner kernel command line. But devicetree looks very good for expressing structured data. That is great and I like it :) > > > > Hoever, I've found that there is a devicetree which can pass more > > structured commands to kernel at boot time :) The devicetree is usually > > used for dscribing hardware configuration, but I think we can expand it > > Devicetree is standardized and documented as hardware description. Yes, at this moment. Can't we talk about some future things? > > for software configuration too (e.g. AOSP and OPTEE already introduced > > firmware node.) Also, grub and qemu already supports loading devicetree, > > so we can use it not only on embedded devices but also on x86 PC too. > > Devicetree is NOT for configuration information. This has been discussed > over and over again in mail lists, at various conferences, and was also an > entire session at plumbers a few years ago: > > https://elinux.org/Device_tree_future#Linux_Plumbers_2016_Device_Tree_Track Thanks, I'll check that. > > There is one part of device tree that does allow non-hardware description, > which is the "chosen" node which is provided to allow communication between > the bootloader and the kernel. Ah, "chosen" will be suit for me :) > There clearly are many use cases for providing configuration information > and other types of data to a booting kernel. I have been encouraging > people to come up with an additional boot time communication channel or > data object to support this use case. So far, no serious proposal that > I am aware of. Hmm, then, can we add "ftrace" node under "chosen" node? It seems that "chosen" is supporting some (flat) properties, and I would like to add a tree of nodes for describing per-event setting. What about something like below? (do we need "compatible" ?) chosen { linux,ftrace { tp-printk; buffer-size-kb = <400>; event0 { event = "..."; }; }; }; [..] > > > > I would like to discuss on some points about this idea. > > > > - Can we use devicetree for configuring kernel dynamically? > > No. Sorry. > > My understanding of this proposal is that it is intended to better > support boot time kernel and driver debugging. As an alternate > implementation, could you compile the ftrace configuration information > directly into a kernel data structure? It seems like it would not be > very difficult to populate the data structure data via a few macros. No, that is not what I intended. My intention was to trace boot up process "without recompiling kernel", but with a structured data. For such purpose, we have to implement a tool to parse and pack the data and a channel to load it at earlier stage in bootloader. And those are already done by devicetree. Thus I thought I could get a piggyback on devicetree. Thank you, -- Masami Hiramatsu