This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: An external interface for _stp_print and _stp_printf in guru mode code?
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