This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Unified tracing buffer
- From: "Martin Bligh" <mbligh at google dot com>
- To: "Masami Hiramatsu" <mhiramat at redhat dot com>
- Cc: "Linux Kernel Mailing List" <linux-kernel at vger dot kernel dot org>, "Linus Torvalds" <torvalds at linux-foundation dot org>, "Thomas Gleixner" <tglx at linutronix dot de>, "Mathieu Desnoyers" <compudj at krystal dot dyndns dot org>, "Steven Rostedt" <rostedt at goodmis dot org>, od at novell dot com, "Frank Ch. Eigler" <fche at redhat dot com>, systemtap-ml <systemtap at sources dot redhat dot com>
- Date: Mon, 22 Sep 2008 13:13:28 -0700
- Subject: Re: Unified tracing buffer
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1222114412; bh=zgYEYiIcY82KWw7llSfsOKaKJfc=; h=DomainKey-Signature:Message-ID:Date:From:To:Subject:Cc: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:References:X-GMailtapped-By; b=fzI/wNnDSEePGCO yk+jt4Gy8MY21SDDsAU6viEr6dF6HEw8sp21OWkz+1mEvqnC+EZ20hbz/gr0hsbtYDk V8Zg==
- Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references:x-gmailtapped-by; b=NZNCoaXfuB28XZ5JuTWq/v0EkxI+wmVcZMJt/Bcr/RKo1obJx8BGD/a+07EjJ32su 5wpYrL/kCKpK+Hlhy8/+A==
- References: <33307c790809191433w246c0283l55a57c196664ce77@mail.gmail.com> <48D7F5E8.3000705@redhat.com>
> I agree to integrate tracing buffer mechanism, but I don't think
> your proposal is the simplest one.
>
> To simplify, I think the layered buffering mechanism is desirable.
> - The lowest layer just provides named circular buffers(both per-cpu and
> uni-buffer in system) and read/write scheme.
> - Next layer provides user/kernel interface including controls.
> - Top layer defines packet(and event) formatting utilities.
> - Additionally, it would better provide some library routines(timestamp,
> event-id synchronize, and so on).
>
> Since this unified buffer is used from different kind of tracers/loggers,
> I don't think all of them(and future tracers) want to be tied down by
> "event-id"+"parameter" format.
> So, Sorry, I disagree about that the tracing buffer defines its *data format*,
> it's just overkill for me.
I think you're right that we can layer this, and we didn't make a particularly
good job of splitting those things out. I'll try to pull together
another revision
to reflect this and other suggested changes.
One thing that I think is still important is to have a unified timestamp
mechanism on everything, so we can co-ordinate different things back
together in userspace from different trace tools, so I intend to keep
that at a lower level, but I think you're right that the event id, etc can
move up into separate layers.