An external interface for _stp_print and _stp_printf in guru mode code?

[Siddhesh Poyarekar]

On 25 April 2012 04:13, Josh Stone <jistone@redhat.com> wrote:
> On 04/24/2012 02:43 PM, Frank Ch. Eigler wrote:
>> For the near future, it should be fine.  We foresee the eventual need
>> to change stp_print's invocation to change its buffering behavior, but
>> maybe even then, some backward-compatility may be preserved.
>
> Those two interfaces have not changed much at all, except to extend the
> printf formats in small ways.  I think for guru-callers we can pretty
> well preserve API compatibility, but I'm not sure we should promise too
> much stability on what *exactly* the output looks like.  I don't
> anticipate much change either way though.
>
> The only real API gotcha I can think of for callers, which perhaps
> should be documented, is what varargs are expected on the stack.  See
> how _stp_vsnprintf() pulls things with va_arg().  It's not too crazy,
> but some difference from "normal" libc, like %p is always int64_t.  We
> also don't support all the crazy extensions that printk has.

I think what I was looking for in terms of documentation can already
be generated using doxygen in the $(srcdir)/runtime directory,
specifically the I/O section in it.

Would it be possible to generate this doxygen documentation
per-release and publish it in the systemtap website alongside the
Tapset Developer's Guide? I personally don't mind my scripts breaking
across releases as long as there is current documentation that I can
use to figure out what changed and modify them accordingly, since most
of my scripts are very specific to problems I am troubleshooting on
that day.

Thanks,
Siddhesh

-- 
http://siddhesh.in