Hi - bookjovi wrote:
> >> [...] > >> ktap use lua language syntax and bytecode as initial implementation, > > > > Interesting approach. I recall we considered it way back when, but > > rejected it for a couple of reasons, including the at-the-time > > perceived unwelcomeness of a serious bytecode interpreter within the > > kernel. > [...] Obviously, the bytecode design is the biggest differences > with systemtap. [...] many Linux box doesn't deliver with gcc, > this is very common in embedded device, even there installed gcc, > but it's hard(impossible) to get matched kernel source. [...] Right, that is a strong attraction. > [...] On clear that, ktap is not a replacement to systemtap, it's > supplementation. FWIW, it would be reasonable to have systemtap emit bytecodes as an alternative backend. All that has been lacking is a powerful and pervasive enough interpreter. The script language is not tied to its implementation via C code generation. That reminds me of your item #4 on your ktap-systemtap comparison: > 4). ktap is safe, whatever you doing in script file, you will never > crash your kernel. This is roughly as true for systemtap as for anything else. The scripts are constrainted to be safe. Kernel crashes that occur are due to occasional bugs in the systemtap runtime library, or down in the kernel facilities being used. You would likely encounter both classes of problems in a kernel-side bytecode interpreter, regardless of the theoretical safety of the scripting language. (This is one of the reasons we've been building out the pure-userspace dyninst-based systemtap backend.) > I will try to make ktap develop progress more faster, and make ktap > source code public available soon. Yes, please. (RFC/experimental code need not be complete before posting; why not develop straight on github?) - FChE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/