Re: Is there a roadmap for the STAP development?

[David Smith <dsmith@redhat.com>]

On 02/14/2017 12:00 PM, Arkady wrote:
> On Tue, Feb 14, 2017 at 6:13 PM, David Smith <dsmith@redhat.com> wrote:

... stuff deleted ...

>>> * Add RPM spec file supporting automatic build of the kernel driver
>>> after kernel updates
>>
>> What do you mean by "the kernel driver"?
> 
> I need to build the module automatically every time the kernel
> updates. I am preparing the RPM/DEB which does the trick, but to have
> a generic example in /docs/examples would be nice or even a script
> which generates such RPM based on the stap command line options.

Hmm, interesting. This sounds a bit like the kmod system that rebuilds
external kernel modules when the kernel gets updated.

>>> * In the _stp_reserve_bytes() return indication that the trace buffer
>>> is overwritten
>>> * Add support for zero copy data transfer
>>
>> You'd have to flesh those last two items out a bit for me to understand
>> what you are looking to do.
> 
> When I send the events from the stap module to the user space I am doing
> event_type* event = _stp_reserve_bytes(sizeof(event_type));
> event->field1 = value1;
> .....
> I do not handle case when _stp_reserve_bytes() starts to overwrite the
> data in the trace buffer. It would be cool to have some feedback that
> buffer is full or is getting full. In some situations it is better to
> drop the event and avoid overwriting the buffer.

As a side note I'll state that you seem to be depending on internal
systemtap interfaces here by using _stp_reserve_bytes(). In general we
try to keep "external" interfaces, like tapsets, compatible between
systemtap versions. There is no such guarantee for internal interfaces.

(That being said, I know of no plans to change _stp_reserve_bytes().)

> In another approach I am planning to use the shared memory for sending
> events from the kernel to the user space in one specific case - very
> frequent system calls. Similarly to transport.c with zero copy API.

Interesting. Yep, that code would be interesting to see.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)