This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: context[2] stuck: (null)
Another approach can be to allow "probe proc" to call blocking APIs
On Fri, Jul 14, 2017 at 8:39 PM, Arkady <arkady.miasnikov@gmail.com> wrote:
> On Fri, Jul 14, 2017 at 7:38 PM, Arkady <arkady.miasnikov@gmail.com> wrote:
>>>>>
>>>>> I would like to have an Initialization probe which allows use of blocking APIs.
>>>>
>>>> .... for example probe begin_interruptable {} and probe end_interruptable {}
>>>
>>> I think you misunderstood me, probably because I didn't express myself
>>> well. Let's try again.
>>>
>>> If you wanted to include the functionality of the allocating the
>>> shared memory to store data and retrieve it via sysfs and debugfs
>>> files in systemtap, what would the user experience look like? Let's
>>> say I'm in a syscall probe. How would I add something to the shared
>>> memory? What would the sysfs/debugfs probe look like?
>>>
>>
>> I would prefer a generic interface allowing me to call blocking APIs
>
> This is, for example, my allocation function
> https://gist.github.com/larytet/643d4a2b932b3d133f6dfca4a4ee8b60
> I do not know how I could define a memory allocation API which does
> everything I will ever need. The same problem with debugfs/sysfs API.
>
> I understand that I am trying to use STAP in a not intended for the
> product application.
>
>>
>>> --
>>> David Smith
>>> Principal Software Engineer
>>> Red Hat