rdreier at cisco.com
Fri Jun 27 21:53:29 PDT 2008
> That's the level sysadmins are never to experience. Tapsets can provide
> a completely abstract and much easier to use interface.
I think we're in agreement on that.
> > Just think about the havoc that changes like
> > "remove struct class_device" would cause for out-of-tree tracing hooks.
> The systemtap language can handle this. There is some preprocessor
> Of course there is the problem of actually updating the code. I would
> be more than happy to see the systemtap scripts to be shipped with the
> kernel so that they can be updated along with the kernel sources.
I think we also agree that kernel developer involvement is required to
create tapsets required for parity/competiveness with DTrace. And my
opinion is that getting real continuing involvement from kernel
developers probably requires that the information be part of the kernel
tree -- whether this is actual systemtap scripts or some other type of
information that can be used by scripts, I don't know.
I say this not for any technical reasons, since there is no technical
reason I can see that prevents all the scripts from being part of a
systemtap package. Rather my gut feeling about the cultural and process
aspects of maintaining this sort of thing is that the majority of kernel
hackers are just not going to pay attention to anything out-of-tree.
More information about the Ksummit-2008-discuss