Only drawback that I can see is that now you can't use the "old" sys_mon module on OS targets anymore. I think that it can still be useful to get an idea about the cycle times and jitter.
It would make sense to implement the rtos_mon (which is actually not restricted to RTOSs) for Linux targets as well, at least there the cycle times and jitter were sometimes useful.
@gautierhattenberger what do you think?

I was thinking about actually merging those two together - so then you would have one struct that combines Sys_mon and Rtos_mon variables. But I didn't do it becase Rtos_mon takes much more memory and wouldnt be used on bare-metal, which might be a waste for old LPC boards.

Linux expansion is welcome, but probably people using ArDrones etc are better suited for the task.

Btw I tested the old sys_mon on Lisa MX with ChibiOS and it just shows 100% CPU usage and the other indicators are constant, while the correct CPU usage from RTOS_MON is ~10%. So it is probably safe to say that people wont miss the old sys_mon for RTOS targets...

It worked fine on Linux targets... the jitter is sometimes really useful information...

by "worked fine" I actually mean that the timing info was working and useful, the cpu_load estimate not...
maybe we should try to add this for the rtos_mon as well?

But since rtos_mon is not implemented currently for linux, it is probably no reason to not merge this...

this will still run the "regular" sys_mon for linux targets, only Chibios (and nps) uses rtos_mon - so you can use it as before

see 451940f#diff-a91ff52aa80c2551abdcfae76b3c93daR52