Em Wed, Oct 24, 2007 at 01:11:18PM +0100, Gerrit Renker escreveu: > | > | perhaps one that could understand types and then could allow > developers > | > | to ask questions like "show me all the places where the field foo of > | > | type bar appears" > | > Hopefully in the next generation of such things may be possible? I was > ^ > | > Indeed! Did you notice the missing word + ... I meant to write `dwarves' :) > and wrote `next generation' since there are apparently already 7 in this > generation.
:) > | Ah, I'm working on some systemtap tapsets, i.e. libraries of probe > | routines, for networking, starting with TCP, but organized in a way > | that can be easily used with DCCP and other net protocols too. > If you could give a shout on the mailing list once it is ready for > testing/deployment, > that would be good. Last year you had a nice tool which automatically > inserted kprobes > at entry/exit points, it was apparently meant to replace an older tool. I > tried it a > few times but then lost track of the revisions. It is frustrating to test > stuff which is > in the middle of a migration to something else. I will, what you are talking about is ctracer, that generates kprobes entry/exit, I'll go to a third revision that will be to generate systemtap scripts instead of kprobes, leveraging on the systemtap safety nets. Yesterday I stopped using _stp_gettimeofday_ns() for the timestamp, switched to get_cycles_sync() and there was no performance drop when using lnlat.stp (the local network latency measurement tool), so it indeed looks promising. > The output looks great and once that is ready, I think it can be of much help > to answer > long pending questions of e.g. how well the packet scheduler really works. Exactly, I want to have a clear picture of where packets sits, and the packet scheduler will be one of the next tapsets I'll be working on. > | And will probably convert net/dccp/dccpprobe.c and tcpprobe to be > | just systemtap scripts and not part of the build process, etc. > I think that dccpprobe.c is the wrong name ... it should really be called > ccid3_probe.c ... > I have been working on printing entries for CCID2, since in ccid2.c there is > no probe support, > and instead ccid2_pr_debug is used for the same purpose all over the place. Indeed, lemme try converting it right now... - Arnaldo - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
