From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id AWWMJTtufF8pIwAAWB0awg (envelope-from ) for ; Tue, 06 Oct 2020 09:16:43 -0400 Received: by simark.ca (Postfix, from userid 112) id 897401EE0F; Tue, 6 Oct 2020 09:16:43 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.lttng.org (lists.lttng.org [167.114.26.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B108D1E58E for ; Tue, 6 Oct 2020 09:16:42 -0400 (EDT) Received: from lists-lttng01.efficios.com (localhost [IPv6:::1]) by lists.lttng.org (Postfix) with ESMTP id 4C5Hzt0lftzS0w; Tue, 6 Oct 2020 09:16:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lists.lttng.org; s=default; t=1601990202; bh=jorX75niftO2yDrmjdehAcG1TCvD38J33kBtIly5anM=; h=To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=BcbLbjkuwH07bbts/d3k5U2H5OFsADGGc0n+aFuukfa/3OQZuVbjHfOspctTT4CuO QcuIEzU+1F2zgALvdeRnZcwretwVOj5a8aOtHYFl62IKNYtkMuStSZRG4pgrdsLIOb 2BzMyGhqslvmkBjgCRc3rjFoPCANuRhpWdr0z9pn9dskfan2k3S5K7EVMyM+jo0S2R QMIEPYtY8AwnDgv+bFP2RZ7GtLqZlEQJSVQ9/FFs7obNrtJ8mO3wCq1x7RbDLcHqmj Iez/vhhX6axu3LvpAZFmTZDMEQvtxP/YyDcNhZQk8yLs133H2alxGfVZc9h+5I2nwn RVN52QdcPA/1g== Received: from west-edge.flir.com (west-edge.flir.com [208.11.40.244]) by lists.lttng.org (Postfix) with ESMTPS id 4C5HyB1sXHzS3g for ; Tue, 6 Oct 2020 09:15:14 -0400 (EDT) Received: from us-bos-mail1.flir.net (10.128.150.174) by us-pdx-mail3.flir.net (10.192.150.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2044.4; Tue, 6 Oct 2020 05:59:58 -0700 Received: from us-bos-mail4.flir.net (10.128.150.252) by us-bos-mail1.flir.net (10.128.150.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Tue, 6 Oct 2020 08:59:57 -0400 Received: from us-bos-mail4.flir.net ([fe80::c466:fd04:8ec1:9f13]) by us-bos-mail4.flir.net ([fe80::c466:fd04:8ec1:9f13%18]) with mapi id 15.01.2044.004; Tue, 6 Oct 2020 08:59:57 -0400 To: "lttng-dev@lists.lttng.org" Thread-Topic: [barectf] Filter trace messages based on log level Thread-Index: AQHWm+CXHG81IHBBcUO1KSlxMmKpWA== Date: Tue, 6 Oct 2020 12:59:57 +0000 Message-ID: <1601988739.4352.32.camel@flir.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.10.39] Content-ID: <1A1C7BE4D0D3F747AA4DF93AB6461682@flir.com> MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 06 Oct 2020 09:16:41 -0400 Subject: [lttng-dev] [barectf] Filter trace messages based on log level X-BeenThere: lttng-dev@lists.lttng.org X-Mailman-Version: 2.1.31 Precedence: list List-Id: LTTng development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "Owen, Mark \(US\) via lttng-dev" Reply-To: "Owen, Mark \(US\)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: lttng-dev-bounces@lists.lttng.org Sender: "lttng-dev" Hi, Thank you for your work on barectf! I'm considering using it with our embedded MCUs that run on bare metal in conjunction with other devices running embedded Linux. The barectf platform back end would primarily be async serial that would be consumed by a device running embedded Linux. Our current home brew trace implementation is limited to a logging a log level and a message string. I see great potential in being able to use the CTF format to output much more information when events occur than just a level and a string. My primary concern with barectf is that our current trace implementation allows us to filter out packets based on log level. I believe this will be necessary for us not to exceed our bandwidth limitation (the serial port may also need to be shared for telemetry and command messaging). My question is, do you think barectf is a good fit for filtering packets based on a logging level? If so, where would you suggest implementing said filtering (e.g. extending the platform API or use a custom API in the specific platform implementation)? I see that the platform API supports enabling or disabling tracing but I am looking for something more granular. Is this something that make sense to be implemented in the platform implementation? My initial thought is that we would probably need to extend our barectf platform, back end implementation to include methods for setting the logging filter level. Before I moved forward I wanted to get your input. Any guidance you could provide here would be very helpful. Thank you, Mark Owen ________________________________ Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation. _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev