Norman,
I know too little about the structure of your profiling environment to give a clear advice on how to integrate it with Genode. The answer depends on the relationship between the user-level portion of your profiling environment and the other processes. If there is no interaction (only interaction with the kernel) and the profiling takes place at a global level (e.g., monitoring the IPC traffic between all processes), the profiling process could be started just alongside the other programs by the init process. But I assume that the profiling environment somehow has to interact with the rest of the system, for example for presenting the profiling result or for getting activated in the first place.
My profiling environment makes use of sampling, where samples are taken of the system execution. These samples are generated in the microkernel as they are based on the timer interrupt within the kernel. The samples are then copied to buffers in user space. Basically, the data that can be collected only pertains to kernel "related" information. If I had more time with my project (which is a Masters project), I would have provided more functionality pertaining to user-space functionality. At this time though, I only really want to focus on the network functionality with regards to experimentation.
Another setting would be to apply profiling as a tool to analyse a Genode subsystem only. This could be achieved by letting the profiler play the role of the parent of this subsystem (similar to init). This way, all requests of the subsystem to the outside will become visible to the profiler at the Genode API level. For example, if the subsystem creates a new process, it will ask the parent (which is then the profiler) to create the corresponding CPU, PD, and RAM sessions. So the profiler can observe how the subsystem interacts with the outside and, in principle, virtualize all services used by the subsystem, or just delegate requests further to the profiler's parent. This way, the profiler could obtain much higher level information about the system than plain kernel events.
That would be very useful for profiling Genode, but as I mentioned before, I don't really have any time to consider this.
Can you elaborate why the profiling code is tied to L4? Would it be possible to generalize it? I ask because a general profiling infra- structure would be valuable not only on OKL4 but also on the other platforms.
I am very aware that generalising my profiling infrastructure would be very valuable, but time constraints prevent me from doing such work. My implementation of the profiling environment was only based on L4/Iguana, and using Wombat as part of testing. I have been looking into Genode as of late due to the other functionality that is already available eg. HTTP server. Also, I figured that porting the user-space portion should be relatively easy to do, since all i would need to worry about is copying the samples to user space. I'm assuming here that Genode is similar to Iguana, but with significantly more functionality than Iguana.
Peter