On Thu, 21 Jan 2010, Frank Ch. Eigler wrote: > > Less passionate analysis would identify a long history of contribution > by the the greater affiliated team, including via merged code and by > and passing on requirements and experiences. The reason I'm so passionate is that I dislike the turn the discussion was taking, as if "utrace" was somehow _good_ because it allowed various other interfaces to hide behind it. And I'm not at all convinced that is true. And I really didn't want to single out system tap, I very much feel the same way abotu some seccomp-replacement "security model that the kernel doesn't even need to know about" thing. So don't take the systemtap part to be the important part, it's the bigger issue of "I'd much rather have explicit interfaces than have generic hooks that people can then use in any random way". I realize that my argument is very anti-thetical to the normal CS teaching of "general-purpose is good". I often feel that very specific code with very clearly defined (and limited) applicability is a good thing - I'd rather have just a very specific ptrace layer that does nothing but ptrace, than a "generic plugin layer that can be layered under ptrace and other things". In one case, you know exactly what the users are, and what the semantics are going to be. In the other, you don't. So I really want to see a very big and immediate upside from utrace. Because to me, the "it's a generic layer with any application you want to throw at it" is a _downside_. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
