From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 572CEC433EF for ; Mon, 22 Nov 2021 10:25:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2E80E6E8EE; Mon, 22 Nov 2021 10:25:51 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id 43A306E40F; Fri, 19 Nov 2021 22:54:32 +0000 (UTC) Received: from rorschach.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 1318F61AE2; Fri, 19 Nov 2021 22:54:29 +0000 (UTC) Date: Fri, 19 Nov 2021 17:54:28 -0500 From: Steven Rostedt To: jim.cromie@gmail.com Subject: Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC Message-ID: <20211119175428.2ab95873@rorschach.local.home> In-Reply-To: References: <20211111220206.121610-1-jim.cromie@gmail.com> <20211111220206.121610-9-jim.cromie@gmail.com> <20211112114953.GA1381@axis.com> <20211116104631.195cbd0b@eldfell> <20211118172401.0b4d722e@eldfell> <41ea83b2-a707-cb6f-521e-070bb12502de@akamai.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 22 Nov 2021 10:25:48 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: quic_saipraka@quicinc.com, Jason Baron , Catalin Marinas , dri-devel , Will Deacon , maz@kernel.org, Vincent Whitchurch , amd-gfx mailing list , Ingo Molnar , Daniel Vetter , Arnd Bergmann , linux-arm-msm@vger.kernel.org, Intel Graphics Development , Pekka Paalanen , Sean Paul , intel-gvt-dev@lists.freedesktop.org, Linux ARM , Sean Paul , Greg KH , LKML , quic_psodagud@quicinc.com, mathieu.desnoyers@efficios.com Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Fri, 19 Nov 2021 15:46:31 -0700 jim.cromie@gmail.com wrote: > > So I could see us supporting subsystem specific trace buffer output > > via dynamic debug here. We could add new dev_debug() variants that > > allow say a trace buffer to be supplied. So in that way subsystems > > could 'opt-out' of having their data put into the global trace buffer. > > And perhaps some subsystems we would want to allow output to both > > buffers? The subsystem specific one and the global one? > > > > * trace_array_printk - Print a message to a specific instance > * @tr: The instance trace_array descriptor > * @ip: The instruction pointer that this is called from. > * @fmt: The format to print (printf format) > * > > what happens when @tr == NULL ? It does nothing, but perhaps crash the kernel. > It could allow up-flow of events to the global instance Absolutely not! Then it's just a reimplementation of trace_printk(). Which I refuse to have. Nothing should just dump to the main instance. Once we allow that, then everyone will be dumping there and you will no longer be able to trace anything because it will be filled with noise. What is allowed is an event that acts like a trace_printk() but is an event, which you can turn off (have default off), and even pick which instance to go to. > > > Thanks, > > > > -Jason > > > > > > So I wonder, is there any conceptual utility to this ? > > echo 1 > instances/foo/filter_up # enable event upflow (or query-time merging?) > > Maybe enabling this causes other files (the ones missing from > instances/foo) to magically appear > so all those filtering capacities also appear. I've been busy doing other things so I haven't been keeping up with this thread (which I need to go back and read). Perhaps it was already stated, but I don't know why you want that. trace-cmd can read several instances (including the top level one) and interleave them nicely, if that is what you are looking for. So can KernelShark. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 137E8C433F5 for ; Fri, 19 Nov 2021 22:54:38 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id F3FC56E817; Fri, 19 Nov 2021 22:54:33 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id 43A306E40F; Fri, 19 Nov 2021 22:54:32 +0000 (UTC) Received: from rorschach.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 1318F61AE2; Fri, 19 Nov 2021 22:54:29 +0000 (UTC) Date: Fri, 19 Nov 2021 17:54:28 -0500 From: Steven Rostedt To: jim.cromie@gmail.com Message-ID: <20211119175428.2ab95873@rorschach.local.home> In-Reply-To: References: <20211111220206.121610-1-jim.cromie@gmail.com> <20211111220206.121610-9-jim.cromie@gmail.com> <20211112114953.GA1381@axis.com> <20211116104631.195cbd0b@eldfell> <20211118172401.0b4d722e@eldfell> <41ea83b2-a707-cb6f-521e-070bb12502de@akamai.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Intel-gfx] [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: quic_saipraka@quicinc.com, Jason Baron , Catalin Marinas , dri-devel , Will Deacon , maz@kernel.org, Vincent Whitchurch , amd-gfx mailing list , Ingo Molnar , Daniel Vetter , Arnd Bergmann , linux-arm-msm@vger.kernel.org, Intel Graphics Development , Pekka Paalanen , Sean Paul , intel-gvt-dev@lists.freedesktop.org, Linux ARM , Greg KH , LKML , quic_psodagud@quicinc.com, mathieu.desnoyers@efficios.com Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Fri, 19 Nov 2021 15:46:31 -0700 jim.cromie@gmail.com wrote: > > So I could see us supporting subsystem specific trace buffer output > > via dynamic debug here. We could add new dev_debug() variants that > > allow say a trace buffer to be supplied. So in that way subsystems > > could 'opt-out' of having their data put into the global trace buffer. > > And perhaps some subsystems we would want to allow output to both > > buffers? The subsystem specific one and the global one? > > > > * trace_array_printk - Print a message to a specific instance > * @tr: The instance trace_array descriptor > * @ip: The instruction pointer that this is called from. > * @fmt: The format to print (printf format) > * > > what happens when @tr == NULL ? It does nothing, but perhaps crash the kernel. > It could allow up-flow of events to the global instance Absolutely not! Then it's just a reimplementation of trace_printk(). Which I refuse to have. Nothing should just dump to the main instance. Once we allow that, then everyone will be dumping there and you will no longer be able to trace anything because it will be filled with noise. What is allowed is an event that acts like a trace_printk() but is an event, which you can turn off (have default off), and even pick which instance to go to. > > > Thanks, > > > > -Jason > > > > > > So I wonder, is there any conceptual utility to this ? > > echo 1 > instances/foo/filter_up # enable event upflow (or query-time merging?) > > Maybe enabling this causes other files (the ones missing from > instances/foo) to magically appear > so all those filtering capacities also appear. I've been busy doing other things so I haven't been keeping up with this thread (which I need to go back and read). Perhaps it was already stated, but I don't know why you want that. trace-cmd can read several instances (including the top level one) and interleave them nicely, if that is what you are looking for. So can KernelShark. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12F8CC433FE for ; Fri, 19 Nov 2021 22:54:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231799AbhKSW5e (ORCPT ); Fri, 19 Nov 2021 17:57:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:46380 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231231AbhKSW5e (ORCPT ); Fri, 19 Nov 2021 17:57:34 -0500 Received: from rorschach.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 1318F61AE2; Fri, 19 Nov 2021 22:54:29 +0000 (UTC) Date: Fri, 19 Nov 2021 17:54:28 -0500 From: Steven Rostedt To: jim.cromie@gmail.com Cc: Jason Baron , Pekka Paalanen , Sean Paul , Sean Paul , Vincent Whitchurch , quic_saipraka@quicinc.com, Catalin Marinas , dri-devel , Will Deacon , maz@kernel.org, amd-gfx mailing list , Ingo Molnar , Daniel Vetter , Arnd Bergmann , linux-arm-msm@vger.kernel.org, Intel Graphics Development , intel-gvt-dev@lists.freedesktop.org, Linux ARM , Greg KH , LKML , quic_psodagud@quicinc.com, mathieu.desnoyers@efficios.com Subject: Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC Message-ID: <20211119175428.2ab95873@rorschach.local.home> In-Reply-To: References: <20211111220206.121610-1-jim.cromie@gmail.com> <20211111220206.121610-9-jim.cromie@gmail.com> <20211112114953.GA1381@axis.com> <20211116104631.195cbd0b@eldfell> <20211118172401.0b4d722e@eldfell> <41ea83b2-a707-cb6f-521e-070bb12502de@akamai.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Fri, 19 Nov 2021 15:46:31 -0700 jim.cromie@gmail.com wrote: > > So I could see us supporting subsystem specific trace buffer output > > via dynamic debug here. We could add new dev_debug() variants that > > allow say a trace buffer to be supplied. So in that way subsystems > > could 'opt-out' of having their data put into the global trace buffer. > > And perhaps some subsystems we would want to allow output to both > > buffers? The subsystem specific one and the global one? > > > > * trace_array_printk - Print a message to a specific instance > * @tr: The instance trace_array descriptor > * @ip: The instruction pointer that this is called from. > * @fmt: The format to print (printf format) > * > > what happens when @tr == NULL ? It does nothing, but perhaps crash the kernel. > It could allow up-flow of events to the global instance Absolutely not! Then it's just a reimplementation of trace_printk(). Which I refuse to have. Nothing should just dump to the main instance. Once we allow that, then everyone will be dumping there and you will no longer be able to trace anything because it will be filled with noise. What is allowed is an event that acts like a trace_printk() but is an event, which you can turn off (have default off), and even pick which instance to go to. > > > Thanks, > > > > -Jason > > > > > > So I wonder, is there any conceptual utility to this ? > > echo 1 > instances/foo/filter_up # enable event upflow (or query-time merging?) > > Maybe enabling this causes other files (the ones missing from > instances/foo) to magically appear > so all those filtering capacities also appear. I've been busy doing other things so I haven't been keeping up with this thread (which I need to go back and read). Perhaps it was already stated, but I don't know why you want that. trace-cmd can read several instances (including the top level one) and interleave them nicely, if that is what you are looking for. So can KernelShark. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 84228C433EF for ; Fri, 19 Nov 2021 22:55:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hzd70L61c+dkymRnbkqYprR7Vm4KbhTuOF/CIUlUWoE=; b=ph7ZpUmebZtsta nUw9sUTsYYJn6GFyebCOyiQxcut7Pw27AgDwoGhq4cBH4vH/WTPAPNPgFW+/6G3K1hzuVTiPP6v3n qm6NsLLzB1Ba9Lp1EMid4rLlpbRhRZ9a60t84bhhqehwjTwDhjpNXTmf5siHbib0ZOXAiyXwSUAx8 aGVGdWhaFlcqfjuiRAFs/wMbm0GJc27CFFR0sxjn3E3NoOZNmT4DNnO48bTS0n/P/vi5B4y1o2fph Um0m5GvgOFyhoknp4T2H8VYNArcNDkT0DnE/MbGCQH87EEu3HjLSNzD8/23VA0gF9fwBHY/Gt3tuM MPPMHuO01OQspuDqQkKA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1moCmD-00BjxZ-F2; Fri, 19 Nov 2021 22:54:37 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1moCm8-00Bjw1-Ow for linux-arm-kernel@lists.infradead.org; Fri, 19 Nov 2021 22:54:34 +0000 Received: from rorschach.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 1318F61AE2; Fri, 19 Nov 2021 22:54:29 +0000 (UTC) Date: Fri, 19 Nov 2021 17:54:28 -0500 From: Steven Rostedt To: jim.cromie@gmail.com Cc: Jason Baron , Pekka Paalanen , Sean Paul , Sean Paul , Vincent Whitchurch , quic_saipraka@quicinc.com, Catalin Marinas , dri-devel , Will Deacon , maz@kernel.org, amd-gfx mailing list , Ingo Molnar , Daniel Vetter , Arnd Bergmann , linux-arm-msm@vger.kernel.org, Intel Graphics Development , intel-gvt-dev@lists.freedesktop.org, Linux ARM , Greg KH , LKML , quic_psodagud@quicinc.com, mathieu.desnoyers@efficios.com Subject: Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC Message-ID: <20211119175428.2ab95873@rorschach.local.home> In-Reply-To: References: <20211111220206.121610-1-jim.cromie@gmail.com> <20211111220206.121610-9-jim.cromie@gmail.com> <20211112114953.GA1381@axis.com> <20211116104631.195cbd0b@eldfell> <20211118172401.0b4d722e@eldfell> <41ea83b2-a707-cb6f-521e-070bb12502de@akamai.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211119_145432_877872_682A767C X-CRM114-Status: GOOD ( 23.78 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 19 Nov 2021 15:46:31 -0700 jim.cromie@gmail.com wrote: > > So I could see us supporting subsystem specific trace buffer output > > via dynamic debug here. We could add new dev_debug() variants that > > allow say a trace buffer to be supplied. So in that way subsystems > > could 'opt-out' of having their data put into the global trace buffer. > > And perhaps some subsystems we would want to allow output to both > > buffers? The subsystem specific one and the global one? > > > > * trace_array_printk - Print a message to a specific instance > * @tr: The instance trace_array descriptor > * @ip: The instruction pointer that this is called from. > * @fmt: The format to print (printf format) > * > > what happens when @tr == NULL ? It does nothing, but perhaps crash the kernel. > It could allow up-flow of events to the global instance Absolutely not! Then it's just a reimplementation of trace_printk(). Which I refuse to have. Nothing should just dump to the main instance. Once we allow that, then everyone will be dumping there and you will no longer be able to trace anything because it will be filled with noise. What is allowed is an event that acts like a trace_printk() but is an event, which you can turn off (have default off), and even pick which instance to go to. > > > Thanks, > > > > -Jason > > > > > > So I wonder, is there any conceptual utility to this ? > > echo 1 > instances/foo/filter_up # enable event upflow (or query-time merging?) > > Maybe enabling this causes other files (the ones missing from > instances/foo) to magically appear > so all those filtering capacities also appear. I've been busy doing other things so I haven't been keeping up with this thread (which I need to go back and read). Perhaps it was already stated, but I don't know why you want that. trace-cmd can read several instances (including the top level one) and interleave them nicely, if that is what you are looking for. So can KernelShark. -- Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0C9FEC433F5 for ; Fri, 19 Nov 2021 22:54:34 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3AAFE6E40F; Fri, 19 Nov 2021 22:54:33 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id 43A306E40F; Fri, 19 Nov 2021 22:54:32 +0000 (UTC) Received: from rorschach.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 1318F61AE2; Fri, 19 Nov 2021 22:54:29 +0000 (UTC) Date: Fri, 19 Nov 2021 17:54:28 -0500 From: Steven Rostedt To: jim.cromie@gmail.com Subject: Re: [PATCH v10 08/10] dyndbg: add print-to-tracefs, selftest with it - RFC Message-ID: <20211119175428.2ab95873@rorschach.local.home> In-Reply-To: References: <20211111220206.121610-1-jim.cromie@gmail.com> <20211111220206.121610-9-jim.cromie@gmail.com> <20211112114953.GA1381@axis.com> <20211116104631.195cbd0b@eldfell> <20211118172401.0b4d722e@eldfell> <41ea83b2-a707-cb6f-521e-070bb12502de@akamai.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: quic_saipraka@quicinc.com, Jason Baron , Catalin Marinas , dri-devel , Will Deacon , maz@kernel.org, Vincent Whitchurch , amd-gfx mailing list , Ingo Molnar , Daniel Vetter , Arnd Bergmann , linux-arm-msm@vger.kernel.org, Intel Graphics Development , Sean Paul , intel-gvt-dev@lists.freedesktop.org, Linux ARM , Sean Paul , Greg KH , LKML , quic_psodagud@quicinc.com, mathieu.desnoyers@efficios.com Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, 19 Nov 2021 15:46:31 -0700 jim.cromie@gmail.com wrote: > > So I could see us supporting subsystem specific trace buffer output > > via dynamic debug here. We could add new dev_debug() variants that > > allow say a trace buffer to be supplied. So in that way subsystems > > could 'opt-out' of having their data put into the global trace buffer. > > And perhaps some subsystems we would want to allow output to both > > buffers? The subsystem specific one and the global one? > > > > * trace_array_printk - Print a message to a specific instance > * @tr: The instance trace_array descriptor > * @ip: The instruction pointer that this is called from. > * @fmt: The format to print (printf format) > * > > what happens when @tr == NULL ? It does nothing, but perhaps crash the kernel. > It could allow up-flow of events to the global instance Absolutely not! Then it's just a reimplementation of trace_printk(). Which I refuse to have. Nothing should just dump to the main instance. Once we allow that, then everyone will be dumping there and you will no longer be able to trace anything because it will be filled with noise. What is allowed is an event that acts like a trace_printk() but is an event, which you can turn off (have default off), and even pick which instance to go to. > > > Thanks, > > > > -Jason > > > > > > So I wonder, is there any conceptual utility to this ? > > echo 1 > instances/foo/filter_up # enable event upflow (or query-time merging?) > > Maybe enabling this causes other files (the ones missing from > instances/foo) to magically appear > so all those filtering capacities also appear. I've been busy doing other things so I haven't been keeping up with this thread (which I need to go back and read). Perhaps it was already stated, but I don't know why you want that. trace-cmd can read several instances (including the top level one) and interleave them nicely, if that is what you are looking for. So can KernelShark. -- Steve