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

[Josh Stone <jistone at redhat dot com>]

On 04/24/2012 02:43 PM, Frank Ch. Eigler wrote:
> 
> siddhesh.poyarekar wrote:
> 
>> [...]  I figured out that systemtap translates the print and printf
>> calls to _stp_print and _stp_printf. It seems to work well in my
>> tests, but I'm guessing that the function name won't necessarily
>> remain stable? [...]
> 
> 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.

Josh