Hello Torsten,
* Torsten Frenzel <frenzel@...28...> [2015-05-27 10:53:59 +0200]:
I'm working with the 15.02 release and found two examples of policy modules, called null and rpc_name. Are there other examples in branches of the repo on how to implement a custom policy module. In general what are the restrictions, when implementing a policy module?
Currently, these two examples are the only ones. Since a policy is basically a stand-alone blob that may be attached at any adress in the address space of a thread it may not contain any relocations or references to the “outer world” and therefore has to provide all that it needs by itself. A while back I started to write a more detailed example (see my 'trace_terminal' branch [1]) including some convenience classes for the trace framework but did not finish it for various reasons.
Is it possible to extract more specific information for a certain event, for example, the name of the destination, that was called. Furthermore, the policy modules for Rpc_call and Rpc_returned events have access to a data structure of type Msgbuf_base. As far as I understood the message buffer contains the arch-depended marshalled data. Is there a generic mechanism to interpret these data in a meaningful way inside policy module or the trace monitor?
The interface is quite generic in this regard and does not provide any specific information. I am afraid there is also no utility which helps you in parsing the data in the message buffer. For now, you have to do this manually.
It would be helpful to accurately timestamp every recorded event with a value of a real time clock. But that would require access to service that provides such an information. Again, I cannot see how to get access to such a service from inside the policy module, because it hasn't access to the Genode runtime environment. Maybe the correct approach would be to use a fast timestamp function inside the policy module and later calculate the real time value in the trace monitor?
Until now, we have always used either the TSC on x86 or the performance counters on ARM to collect a timestamp (it is implemented for all platforms accordingly in the 'trace/timestamp.h' header. Combing that with information provided by a real time clock is normally done by the trace monitor.
Is it possible to disable/enable specific types of events (, may be using the Trace::Control data structure)?
Well, you can selectively enable or disable specfic types through the trace policy module but there is no explicit API for that.
Is there a mechanism that the trace monitor is notified, when a trace-buffer is full or has reached a threshold?
No.
When I played around with the test_trace program, I noticed that loading more than policy module into core fails. After some investigations I found that the slab_size for the constructed allocator used in the Policy_registry class for Trace::Policy objects is only 4 bytes, but Trace::Policy objects have a larger size of 26 bytes. When I changed the constructor in the session component as shown below everything works fine. So for some reason the compiler selects the Avl_node_base::Policy class in the template.
diff -r ./base/src/core/include/trace/session_component.h . 40,41c40,41
< Tslab<Trace::Policy, 4096> _policies_slab;
Tslab<Policy, 4096> _policies_slab;
Nice catch! Johannes reported this problem [2] some time ago but we did not come around to tackle it. It would be nice if you could note your finding in the issue on github. Thanks in advance.
Regards Josef
[1] https://github.com/cnuke/genode/commits/trace_terminal [2] https://github.com/genodelabs/genode/issues/1508