Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp472965img; Fri, 22 Mar 2019 01:58:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqwRN7HA7EIOa5Tpxl1JAk/89GcHg1+uBlACTRIQIRWqALM1ka13UmFLIdUhv3fIJDFVJzd0 X-Received: by 2002:a63:65c4:: with SMTP id z187mr7730213pgb.102.1553245120775; Fri, 22 Mar 2019 01:58:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553245120; cv=none; d=google.com; s=arc-20160816; b=kO6sOoZbafRNFE3Zta9CyHJE617zDGepRvOoAKgmLtdDIXMsssKqMHDdrwh1juM7XR 15iq0b9qzbeq9rYbkRXAhlyqnZZNQSBiDLuHm9jY7Y5a4c/2+n9WkNZbASqMnG5WdMKe AA3YaSCZWMAu3zgJb3vemRiZIMAjGdmzB0zLFOtUwDDYQSttSCt9x5kZAiUk+37HBawg PXdkiOtY71a54uYfTaOjnwAXLLpwzIB6+Qfi6q2TqCyDw3rp4RsDlltqmKAY6lHWIT0o mlaTPGhsttsbzVAg8VOScA+OqwYwkWKu6WPeVi3/JlDpU+YG6bGQ5pm06zgkLyuLjpzY b/nA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=14F5q/AtfCV+Igude3Yk6Cm5XIY93wGVQyNrYkuBmWc=; b=bh+iOkKeqH00YPUwx5ILPEWtnmj9KYRTPVNtW5D4KW/IZyT1b3+PyKy1CZdFXOa5Qx frmR4GCM6/+IxUDJpyCbgqkPL0TlRsD3/oVbhgALNm6pXQRWMPNdAQK82Iqcx5FO6auF 8LXUsxxdsyP4+ZDI3VQbUuRNYU3FoVTzcQaznDkvUa1q37vyfUUcgoUPAF7cjXQf99JM cnSdcHyEJqW05tB8PbPHvD6c9ZVkdZMQZyl5UneauUIsMk8QX+eLuCGlEoobMYpb46U8 5qZdnzfIMz/gd83U7FCJggwgQ8JVGdBd3VRYO9vdZZrc/Bp1zk4/1xdbOWBjyrr+2snY 3OMg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bg8si6260244plb.109.2019.03.22.01.58.25; Fri, 22 Mar 2019 01:58:40 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727798AbfCVI4R (ORCPT + 99 others); Fri, 22 Mar 2019 04:56:17 -0400 Received: from mga18.intel.com ([134.134.136.126]:35747 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727581AbfCVI4R (ORCPT ); Fri, 22 Mar 2019 04:56:17 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2019 01:56:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,256,1549958400"; d="asc'?scan'208";a="129196070" Received: from pipin.fi.intel.com (HELO localhost) ([10.237.72.175]) by orsmga006.jf.intel.com with ESMTP; 22 Mar 2019 01:56:14 -0700 From: Felipe Balbi To: Steven Rostedt , Ingo Molnar Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: [RFC] Allowing modules to control tracing subsystem Date: Fri, 22 Mar 2019 10:56:10 +0200 Message-ID: <87h8bvffth.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi guys, I've been thinking about turning my f-trace.c USB function [1] into an implementation of the USB Debug Class [2]. In order to support all requests, I would need means to control parts of the tracing subsystem, for example enabling and disabling tracing, flushing the trace buffer, changing trace buffer size, choose which trace events to enable, etc. Some of those functions (e.g. print_trace_line()) are available for things like trace_kdb.c [3], but they're not available for modules; i.e. they're not exported symbols. This will involve a rather large change to tracing subsystem however we could rely on such infrastructure for remote debugging of e.g. IVIs, phones, etc. The USB Debug Class already predicts the presence of JTAG access and Hardware tracing modules to be exported over USB. It also allows for GDB-type access. Adding our linux kernel tracing would make it into a complete tracing solution. In order to fully support this we would need, not only to expose some internal trace functions for modules, but I suppose the trace format would have to be slightly better defined so that it be decoded remotely give access to vmlinux. What do you guys think about this? Would this be something that folks would be interested in? Currently we can only export ftrace data, not trace events or anything else. Ideally we would export raw trace buffer entries to be decoded at a later moment. cheers [1] https://marc.info/?i=3D20190321094748.7031-1-felipe.balbi@linux.intel.c= om [2] https://www.usb.org/sites/default/files/documents/usb_debug_class_rev_1= _0_final_0.pdf [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree= /kernel/trace/trace_kdb.c#n20 =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlyUoyoACgkQzL64meEa mQbbRg/7BMCGnkVhR0Fm71yJeRWftXIuTTvOV6tCFIqoK+PrQ4Ev98tVZ7mcHpRI dYQFh+9CLDIlOu/e91E+nCQEeE7yJ5UnDTz7DmpcDRdJ/nzvP1Jglfzcul8oxABe LdP5nweW/zDzSXn5DuYvL38Js+mYcWtODx3dg+RGNUXkLRkxdgSAoxpWVCZERrso xFYMpK+qLztqB6LOn1rJh/EctEZlsJyDDix7jaoOkEyKsakkGJHG9uU9mDzl3WTM IVhIGoJ32RI18qugTZ89lZIrjEbr6I/Mlns24bgOJU+x3LO7/uqPY87gQZSqibSB sub9forJRPs7iUxmjNAqfR51XxyQ9yu4HRXSFnWuBvOvVhq33xfRqgwSs4njtBQc ZLj7EMJ+UOnVop8//uDxkEeppnRjLXD3Yo3K1eW1uJC/wjKqL8riWifEhbEHCyVX 4AqZE5ssoE18RCduoXGf2N3/BKVqTbEo2JVaYeXLuCwK0AXsH63w0Qsa/LLT90kd GKmOowgC6fbW02Gmg0dheMwJhbYErUpZZ2eRxoDt29mI4qD3122Hb6R2rR9h8LgN T1uApLwOdwg7XfiMQwux6M7F+4wGseEUYOb1o8H4cOg7DeC6TCsV1xElOwDiUvVJ tIoptUEB+xa1grtVnbJxw3u43iRqG9jmvt5S92GeC5vi3Lq8TDs= =WTws -----END PGP SIGNATURE----- --=-=-=--