Re: [RFC PATCH 00/28] ktap: A lightweight dynamic tracing tool for Linux

[Ingo Molnar <mingo@kernel.org>]

* Alexei Starovoitov <ast@plumgrid.com> wrote:

> [...]
>
> It seems that your definition of 'safe ktap' is that user cannot break
> kernel if he uses ktap scripting syntax.
> In that sense ktap is not much different from stap.
> 
> Overall it seems you view ktap bytecode as a continuation
> of ktap syntax.
> ktap language allows to read pid,uid,tid, so they were added as
> separate instructions to ktap bytecode...
> ktap allows dump of a table, so kernel has to do tab_histdump()
> including sorting of fields and printf formatting.
> What if ktap user wants a different table dump?
> or new features from the language?
> keep extending bytecode for every printf tweak is not a great solution.
> 
> I think design approach to ktap needs to change.
> What I'm proposing is the following:
> - keep ktap syntax as-is, but remove loops
> - ktap style of accessing tables is definitely less verbose then C,
>  so keep it, but don't let compiled program to own the memory
> - keep table dump as-is, but do it in userspace instead

I'd suggest using C syntax instead initially, because that's what the 
kernel is using.

The overwhelming majority of people probing the kernel are 
programmers, so there's no point in inventing new syntax, we should 
reuse existing syntax!

That is one reason why for example the (very simple!) ftrace filter 
language tries to mimic C syntax.

Especially as C is simpler for an important category, filters:

> Though I think C as a language to express filters is simpler,
> ktap syntax is fine as well.

Thanks,

	Ingo