I am aware of the differences. My goal was not to recreate dtrace 1 to 1, it was to extend it with trade-offs. I've heard the argument made many times, my syste

I am aware of the differences. My goal was not to recreate dtrace 1 to 1, it was to extend it with trade-offs. I've heard the argument made many times, my system is not meant to be deployed on end point user systems. A recreation obeying the same constraints of dtrace could be constructed, it would simply involve swapping the scripting system for another. If your argument is that loops are unsafe, please go look at ebpf, which has loops. If you think user defined functions are unsafe, go look at ebpf again - it's nearly C. If your argument is shipping code from user to kernel is unsafe, go look at ebpf byte code, I could easily implement signing to validate only trusted plugins can load. Your argument is close minded. These are trade-offs, and can be easily changed to obey different constraints. My system open sources previously undocumented kernel interfaces. If you dislike the constraints I chose, fork it and go rebuild dtrace exactly, it's not that I'm not solving a real problem - I'm just solving one you fail to understand.