Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: mbligh@google.com (Martin Bligh)
Subject: [ltt-dev] LTTng specialized probes
Date: Mon, 6 Oct 2008 08:37:17 -0700	[thread overview]
Message-ID: <33307c790810060837q4e0a6a45l4ed574e5b30915e1@mail.gmail.com> (raw)
In-Reply-To: <20081006152618.GA5946@Krystal>

On Mon, Oct 6, 2008 at 8:26 AM, Mathieu Desnoyers
<compudj at krystal.dyndns.org> wrote:
> The idea is that someone who want to add a new instrumentation site in
> the Linux kernel does not have to write a specialized probe up front.
> The format string parser will take care of writing the typed data into
> the buffers (default behavior), but can still overridden by a
> specialized function which will expect the format string arguments and
> serialize those into the buffers.

OK, it seemed mandatory to me, but if it's not, that's good.

> About what we discussed in Portland and where Steven is currently going:
> it does not provide any kind of binary standard to export the data
> between different platforms or even from kernel 64-bits kernel to
> 32-bits userland. Steven also cleary states that he doesn't care about
> exporting this data to userspace in binary format. He wants a
> supplementary layer to do this formatting, which I don't think will
> produce the performance results we are looking for. Plus, I think
> feeding the data through the kernel which recorded the information to
> decode it is the wrong approach, especially when the system which
> recorded such information is a small embedded device, where getting the
> data _out_ is already non-trivial. Feeding it back in seems a bit crazy.

I know he wants the in-kernel parsing for ease-of-use, and getting things
upstream ... but it seemed to me that there was nothing in what he was
doing that made it impossible to get the data in binary form out to userspace.
Exporting the buffers is obviously easy. I was under the impression you were
recording strings in the buffers anyway, in which case I don't see why you
care, but I might be totally mistaken. Even so, it seems what we'd need
is just to make sure the buffer headers were exported, plus the decoding
functions - making C files that will link with both the kernel and into a
userspace library would be a little tricky, but not impossible?




  reply	other threads:[~2008-10-06 15:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5df78e1d0809231814i4b9b98eeyfb9746e5dbb9eb72@mail.gmail.com>
     [not found] ` <20080924072503.GA15570@bolzano.suse.de>
     [not found]   ` <532480950809240032t644448f7lc4fdc0dffca69b9@mail.gmail.com>
2008-10-06 14:11     ` Mathieu Desnoyers
2008-10-06 15:14       ` Martin Bligh
2008-10-06 15:26         ` Mathieu Desnoyers
2008-10-06 15:37           ` Martin Bligh [this message]
2008-10-06 15:56             ` Mathieu Desnoyers
2008-10-06 17:55       ` Jiaying Zhang
2008-10-06 17:55         ` Jiaying Zhang
2008-10-06 17:55         ` Jiaying Zhang
     [not found]         ` <5df78e1d0810071116i2e9790cdx8d5854dbfa50cfaf@mail.gmail.com>
2008-10-07 21:28           ` Michael Davidson
2008-10-07 21:28             ` Michael Davidson
2008-10-07 21:28             ` Michael Davidson
2008-10-08  0:07             ` Mathieu Desnoyers
2008-10-08 15:56               ` Jan Kiszka
2008-10-08 15:56                 ` Jan Kiszka
2008-10-08 15:56                 ` Jan Kiszka
2008-10-08 16:06                 ` Martin Bligh
2008-10-09  2:43                   ` Mathieu Desnoyers
2008-10-09  2:24                 ` Mathieu Desnoyers
2008-10-09  2:24                   ` Mathieu Desnoyers
2008-10-09  2:24                   ` Mathieu Desnoyers
2008-10-09  3:04               ` Michael Davidson
2008-10-09  3:04                 ` Michael Davidson
2008-10-09  3:04                 ` Michael Davidson
2008-10-09 15:28                 ` Mathieu Desnoyers
2008-10-09 15:39                   ` Martin Bligh
2008-10-09 16:15                     ` Mathieu Desnoyers
2008-10-09 16:28                       ` Martin Bligh
2008-10-09 16:55                         ` Mathieu Desnoyers
2008-10-08  0:26         ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=33307c790810060837q4e0a6a45l4ed574e5b30915e1@mail.gmail.com \
    --to=mbligh@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox