From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753596AbYI3UVZ (ORCPT ); Tue, 30 Sep 2008 16:21:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752052AbYI3UVR (ORCPT ); Tue, 30 Sep 2008 16:21:17 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.123]:46467 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751669AbYI3UVR (ORCPT ); Tue, 30 Sep 2008 16:21:17 -0400 Date: Tue, 30 Sep 2008 16:21:14 -0400 (EDT) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: "Frank Ch. Eigler" cc: Mathieu Desnoyers , Martin Bligh , Peter Zijlstra , linux-kernel@vger.kernel.org, prasad@linux.vnet.ibm.com, Linus Torvalds , Thomas Gleixner , od@suse.com, Andrew Morton , hch@lst.de, David Wilder , Tom Zanussi Subject: Re: [RFC PATCH] LTTng relay buffer allocation, read, write In-Reply-To: <20080930200112.GD27822@redhat.com> Message-ID: References: <20080929155004.GA11029@Krystal> <1222709445.23876.70.camel@twins.programming.kicks-ass.net> <20080929203124.GA23070@Krystal> <33307c790809301022q2821ecc7iabf41eb513707e0c@mail.gmail.com> <33307c790809301023v1b0755fbsab1bbfa9bfaad58@mail.gmail.com> <20080930181436.GA19690@Krystal> <20080930183531.GA20670@Krystal> <20080930200112.GD27822@redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 30 Sep 2008, Frank Ch. Eigler wrote: > On Tue, Sep 30, 2008 at 03:43:45PM -0400, Steven Rostedt wrote: > > [...] > > On Tue, 30 Sep 2008, Mathieu Desnoyers wrote: > > > > > > You are actually using them to put redundant information that could be > > > encoded differently and thus save 4 bits per event records, more or less > > > what will be needed by most tracers (15 IDs, 1 reserved for an extended > > > ID field). > > > > I really like the idea of keeping the tracer event ids out of the ring > > buffer logic. > > That's fine for a ring buffer that only ever contains data from one > event source. How do you imagine multiplexing working, where one > wants to grep a single debugfs file that contains data from different > event sources? Punt to another layer? Field goal! Yes! That is exactly what I want. If your trace has only one event, why would it want to record them? The event id belongs in the tracer layer not the ring buffer layer. I would like to make a "trace_buffer" layer that includes all of this. -- Steve