[ltt-dev] LTTng specialized probes

[Martin Bligh]

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?