* RE: Sockets tapset and script
@ 2006-11-22 0:45 Stone, Joshua I
0 siblings, 0 replies; 6+ messages in thread
From: Stone, Joshua I @ 2006-11-22 0:45 UTC (permalink / raw)
To: David Smith, Martin Hunt; +Cc: Mike Mason, systemtap
On Tuesday, November 21, 2006 1:27 PM, David Smith wrote:
> Hmm, perhaps we need a bugzilla asking to support array
> initialization, perhaps like this:
> global xyz = { 1, 5, 10, 15 }
> global abc = { "zero", "one", "two", "three", "four" }
Remember that these are really associative arrays (à la maps in C++ STL, hashes in Perl, dictionaries in Python, etc.). So while your example implies a zero-based integer key, that's not necessarily the case.
We could treat it that missing keys are implied to count from zero, and then provide a syntax for specifying keys explicitly as well.
global sig_num_to_name = { 1:"SIGHUP", 2:"SIGINT", ...}
global sig_name_to_num = { "SIGHUP":1, "SIGINT":2, ...}
global times_table = { [1,2]:2, [5,6]:30, ...}
Josh
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sockets tapset and script
2006-11-28 2:23 ` Mike Mason
@ 2006-11-28 23:57 ` David Smith
0 siblings, 0 replies; 6+ messages in thread
From: David Smith @ 2006-11-28 23:57 UTC (permalink / raw)
To: Mike Mason; +Cc: Martin Hunt, systemtap
Mike Mason wrote:
> Martin Hunt wrote:
>> On Fri, 2006-11-17 at 14:26 -0800, Mike Mason wrote:
>> Since yesterday, we can now access parameters in return probes (BZ
>> 1382). This could simplify some of your script because yo no longer need
>> to cache parameters on entry probes and then lookup their values in the
>> return probe.
>
> Based on later posts, I assume this still doesn't work and I shouldn't
> remove the parameter caching in my script just yet.
> Please confirm if this is true.
Accessing target variables in return probes currently works, for some
applications.
There are two major outstanding bugs:
(1) The current code can get confused and fail to find the cached
parameters if two different threads intersperse function entries/exits.
I should have this one fixed late today or early tomorrow.
(2) Accessing the target variables in a loop is broken. A workaround is
to assign the target variable to a temp variable before the loop and
then use the temp variable in the loop. This one is going to require
some re-architecture work, so I'm unsure when it will get fixed.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sockets tapset and script
2006-11-21 17:23 ` Martin Hunt
2006-11-22 0:05 ` David Smith
@ 2006-11-28 2:23 ` Mike Mason
2006-11-28 23:57 ` David Smith
1 sibling, 1 reply; 6+ messages in thread
From: Mike Mason @ 2006-11-28 2:23 UTC (permalink / raw)
To: Martin Hunt; +Cc: systemtap
Martin Hunt wrote:
> On Fri, 2006-11-17 at 14:26 -0800, Mike Mason wrote:
>> Attached is a sockets tapset and a script that uses the tapset.
>
> Very nice!
>
> It seems like tokenize() and str2long() (perhaps renamed simply strtol)
> would be good candidates to put in the string tapset so others could use
> them.
>
> Since yesterday, we can now access parameters in return probes (BZ
> 1382). This could simplify some of your script because yo no longer need
> to cache parameters on entry probes and then lookup their values in the
> return probe.
Based on later posts, I assume this still doesn't work and I
shouldn't remove the parameter caching in my script just yet.
Please confirm if this is true.
Thanks,
Mike
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sockets tapset and script
2006-11-21 17:23 ` Martin Hunt
@ 2006-11-22 0:05 ` David Smith
2006-11-28 2:23 ` Mike Mason
1 sibling, 0 replies; 6+ messages in thread
From: David Smith @ 2006-11-22 0:05 UTC (permalink / raw)
To: Martin Hunt; +Cc: Mike Mason, systemtap
Martin Hunt wrote:
> On Fri, 2006-11-17 at 14:26 -0800, Mike Mason wrote:
>> Attached is a sockets tapset and a script that uses the tapset.
>
> Very nice!
>
> It seems like tokenize() and str2long() (perhaps renamed simply strtol)
> would be good candidates to put in the string tapset so others could use
> them.
>
> Since yesterday, we can now access parameters in return probes (BZ
> 1382). This could simplify some of your script because yo no longer need
> to cache parameters on entry probes and then lookup their values in the
> return probe.
>
> In print_activity, you can simply do this:
> foreach ([pid, prot, fam] in sk_pid- limit max) { ... }
> Then you don't need "if (!--max) break"
> This is a bit cleaer and generates faster code.
>
>> Mapping functions are something I think script writers need, not just for sockets,
>> but in a lot of other areas. Some of these functions using mapping arrays.
>> What do people think of this approach?
>
> It is simple and elegant. However, in time-critical code (which your
> example is probably not) it may be better to write them in C. A
> complicated example would be what I did in errno.stp. Of course that
> example doesn't include the reverse map.
Mike,
One thing you might want to think about is instead of initializing your
mapping arrays on first use would be to put their initialization in a
begin probe. You'd pay more up front cost but if your probe code was
time-critical (which your use might not be) you wouldn't be slowed down
by mapping array initialization in the probe itself. The optimizer will
optimize out the array and array initialization if the array isn't
actually used anywhere.
This would be similar to what happens when you do "global xyz = 1" - a
begin probe is generated that sets up the initial value of xyz. Hmm,
perhaps we need a bugzilla asking to support array initialization,
perhaps like this:
global xyz = { 1, 5, 10, 15 }
global abc = { "zero", "one", "two", "three", "four" }
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sockets tapset and script
2006-11-17 23:19 Mike Mason
@ 2006-11-21 17:23 ` Martin Hunt
2006-11-22 0:05 ` David Smith
2006-11-28 2:23 ` Mike Mason
0 siblings, 2 replies; 6+ messages in thread
From: Martin Hunt @ 2006-11-21 17:23 UTC (permalink / raw)
To: Mike Mason; +Cc: systemtap
On Fri, 2006-11-17 at 14:26 -0800, Mike Mason wrote:
> Attached is a sockets tapset and a script that uses the tapset.
Very nice!
It seems like tokenize() and str2long() (perhaps renamed simply strtol)
would be good candidates to put in the string tapset so others could use
them.
Since yesterday, we can now access parameters in return probes (BZ
1382). This could simplify some of your script because yo no longer need
to cache parameters on entry probes and then lookup their values in the
return probe.
In print_activity, you can simply do this:
foreach ([pid, prot, fam] in sk_pid- limit max) { ... }
Then you don't need "if (!--max) break"
This is a bit cleaer and generates faster code.
> Mapping functions are something I think script writers need, not just for sockets,
> but in a lot of other areas. Some of these functions using mapping arrays.
> What do people think of this approach?
It is simple and elegant. However, in time-critical code (which your
example is probably not) it may be better to write them in C. A
complicated example would be what I did in errno.stp. Of course that
example doesn't include the reverse map.
I see you worked around the issue with nonexistent map entries are
returned as 0. Also, since setting a map entry to 0 deletes it, there is
no reason to do
fam_str2num["UNSPEC"] = 0
What you could have done is add 1 to all of the entries, which
simplifies your code considerably:
function sock_fam_str2num:long (family:string)
{
if (!fam_s2s_init) _fam_str2num_init()
return fam_str2num[family] - 1
}
function sock_fam_num2str:string (family:long)
{
if (!fam_n2s_init) _fam_num2str_init()
str = fam_num2str[family+1]
if (str == "") str = sprintf ("%d", family)
return str
}
One possible issue is if we accumulate too many of these arrays in
tapsets, they could take significant space. The language currently has
no way to declare an array static and therefore all arrays have
MAXMAPENTRIES preallocated for their use.
Martin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Sockets tapset and script
@ 2006-11-17 23:19 Mike Mason
2006-11-21 17:23 ` Martin Hunt
0 siblings, 1 reply; 6+ messages in thread
From: Mike Mason @ 2006-11-17 23:19 UTC (permalink / raw)
To: systemtap
[-- Attachment #1: Type: text/plain, Size: 4731 bytes --]
Attached is a sockets tapset and a script that uses the tapset. I thought I'd post them for review even though they're not done. The tapset just contains what I needed to write the script. More comments, probes and helper functions are needed. I also need to write some tests.
The tapset contains functions to map numbers to strings and strings to numbers for:
- protocols
- protocol families
- socket types
- socket states
- socket flags
- message flags
Mapping functions are something I think script writers need, not just for sockets, but in a lot of other areas. Some of these functions using mapping arrays. What do people think of this approach?
The script (socktop) prints socket traffic for the top n processes and, optionally, network device traffic. Besides being a useful script (I hope), it demonstrates a few methods that should be applicable to many scripts:
- using a shell script to process command line options
- filtering on multiple categories (in this case, process ID and name, user name, protocol, protocol family and socket type)
- passing array-like data from a shell script to a systemtap script and tokenizing that data in systemtap
- passing in a timezone adjustment
Also, note the sign bit hack in the return probes. This is something I'd like to remove before posting the script on the wiki (hint, hint :-).
Here's some example output from socktop:
[root@localhost probes]# ./socktop -P TCP -P UDP -d
======================= Fri Nov 17 14:10:57 2006 ========================
------------------------------- PROCESSES -------------------------------
PID UID #SEND #RECV SEND_KB RECV_KB PROT FAMILY COMMAND
14668 0 0 2546 0 3635 TCP INET firefox-bin
6765 0 10 10 31 0 TCP INET Xvnc
-------------------------------- DEVICES --------------------------------
DEV #XMIT #RECV XMIT_KB RECV_KB
eth0 1396 2643 121 3769
=========================================================================
======================= Fri Nov 17 14:11:02 2006 ========================
------------------------------- PROCESSES -------------------------------
PID UID #SEND #RECV SEND_KB RECV_KB PROT FAMILY COMMAND
14668 0 0 2457 0 3487 TCP INET firefox-bin
6765 0 11 11 14 0 TCP INET Xvnc
29852 0 2 0 0 0 TCP INET6 sshd
-------------------------------- DEVICES --------------------------------
DEV #XMIT #RECV XMIT_KB RECV_KB
eth0 1309 2533 98 3620
=========================================================================
======================= Fri Nov 17 14:11:07 2006 ========================
------------------------------- PROCESSES -------------------------------
PID UID #SEND #RECV SEND_KB RECV_KB PROT FAMILY COMMAND
14668 0 0 1886 0 2676 TCP INET firefox-bin
6765 0 83 292 532 2 TCP INET Xvnc
29852 0 1 0 0 0 TCP INET6 sshd
-------------------------------- DEVICES --------------------------------
DEV #XMIT #RECV XMIT_KB RECV_KB
eth0 1501 2478 624 2797
=========================================================================
[root@localhost probes]# ./socktop -d
======================= Fri Nov 17 14:09:45 2006 ========================
------------------------------- PROCESSES -------------------------------
PID UID #SEND #RECV SEND_KB RECV_KB PROT FAMILY COMMAND
14668 0 0 2796 0 3969 TCP INET firefox-bin
6765 0 221 284 535 429 IP LOCAL Xvnc
6909 0 77 139 277 276 IP LOCAL wnck-applet
14668 0 53 79 103 220 IP LOCAL firefox-bin
6840 0 61 125 26 17 IP LOCAL metacity
6902 0 21 27 21 21 IP LOCAL nautilus
6765 0 11 11 32 0 TCP INET Xvnc
6900 0 3 7 0 0 IP LOCAL gnome-panel
6820 0 0 8 0 0 IP LOCAL gnome-settings-
1610 0 1 3 0 0 IP NETLINK ifconfig
-------------------------------- DEVICES --------------------------------
DEV #XMIT #RECV XMIT_KB RECV_KB
eth0 1516 2888 129 4115
=========================================================================
All comments are welcome.
Mike Mason
[-- Attachment #2: sockets.tgz --]
[-- Type: application/x-compressed, Size: 7633 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-11-28 16:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-11-22 0:45 Sockets tapset and script Stone, Joshua I
-- strict thread matches above, loose matches on Subject: below --
2006-11-17 23:19 Mike Mason
2006-11-21 17:23 ` Martin Hunt
2006-11-22 0:05 ` David Smith
2006-11-28 2:23 ` Mike Mason
2006-11-28 23:57 ` David Smith
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).