#!/usr/local/bin/ruby # # biorhythm.rb - # $Release Version: $ # $Revision$ # $Date$ # by Yasuo OHBA(STAFS Development Room) # # -- # # # # probably based on: # # Newsgroups: comp.sources.misc,de.comp.sources.os9 # From: fkk@stasys.sta.sub.org (Frank Kaefer) # Subject: v41i126: br - Biorhythm v3.0, Part01/01 # Message-ID: <1994Feb1.070616.15982@sparky.sterling.com> # Sender: kent@sparky.sterling.com (Kent Landfield) # Organization: Sterling Software # Date: Tue, 1 Feb 1994 07:06:16 GMT # # Posting-number: Volume 41, Issue 126 # Archive-name: br/part01 # Environment: basic, dos, os9 include Math require "date.rb" require "parsearg.rb" require "parsedate.rb" def usage() print "Usage:\n" print "biorhythm.rb [options]\n" print " options...\n" print " -D YYYYMMDD(birthday) : use default values.\n" print " --sdate | --date YYYYMMDD : use system date; use specified date.\n" print " --birthday YYYYMMDD : specifies your birthday.\n" print " -v | -g : show values or graph.\n" print " --days DAYS : graph range (only in effect for graphs).\n" print " --help : help\n" end $USAGE = 'usage' def printHeader(y, m, d, p, w) print "\n>>> Biorhythm <<<\n" printf "The birthday %04d.%02d.%02d is a %s\n", y, m, d, w printf "Age in days: [%d]\n\n", p end def getPosition(z) pi = Math::PI z = Integer(z) phys = (50.0 * (1.0 + sin((z / 23.0 - (z / 23)) * 360.0 * pi / 180.0))).to_i emot = (50.0 * (1.0 + sin((z / 28.0 - (z / 28)) * 360.0 * pi / 180.0))).to_i geist =(50.0 * (1.0 + sin((z / 33.0 - (z / 33)) * 360.0 * pi / 180.0))).to_i return phys, emot, geist end def parsedate(s) ParseDate::parsedate(s).values_at(0, 1, 2) end def name_of_week(date) Date::DAYNAMES[date.wday] end # # main program # parseArgs(0, nil, "vg", "D:", "sdate", "date:", "birthday:", "days:") if $OPT_D dd = Date.today bd = Date.new(*parsedate($OPT_D)) ausgabeart = "g" else if $OPT_birthday bd = Date.new(*parsedate($OPT_birthday)) else STDERR.print("Birthday (YYYYMMDD) : ") unless (si = STDIN.gets.chop).empty? bd = Date.new(*parsedate(si)) end end if !bd STDERR.print "BAD Input Birthday!!\n" exit() end if $OPT_sdate dd = Date.today elsif $OPT_date dd = Date.new(*parsedate($OPT_date)) else STDERR.print("Date [ for Systemdate] (YYYYMMDD) : ") unless (si = STDIN.gets.chop).empty? dd = Date.new(*parsedate(si)) end end dd ||= Date.today if $OPT_v ausgabeart = "v" elsif $OPT_g ausgabeart = "g" else STDERR.print("Values for today or Graph (v/g) [default g] : ") ausgabeart = STDIN.gets.chop end end if ausgabeart == "v" printHeader(bd.year, bd.month, bd.day, dd - bd, name_of_week(bd)) print "\n" phys, emot, geist = getPosition(dd - bd) printf "Biorhythm: %04d.%02d.%02d\n", dd.year, dd.month, dd.day printf "Physical: %d%%\n", phys printf "Emotional: %d%%\n", emot printf "Mental: %d%%\n", geist print "\n" else if $OPT_days display_period = $OPT_days.to_i elsif $OPT_D display_period = 9 else STDERR.printf("Graph for how many days [default 10] : ") display_period = STDIN.gets.chop if display_period.empty? display_period = 9 else display_period = display_period.to_i - 1 end end printHeader(bd.year, bd.month, bd.day, dd - bd, name_of_week(bd)) print " P=physical, E=emotional, M=mental\n" print " -------------------------+-------------------------\n" print " Bad Condition | Good Condition\n" print " -------------------------+-------------------------\n" (dd - bd).step(dd - bd + display_period) do |z| phys, emot, geist = getPosition(z) printf "%04d.%02d.%02d : ", dd.year, dd.month, dd.day p = (phys / 2.0 + 0.5).to_i e = (emot / 2.0 + 0.5).to_i g = (geist / 2.0 + 0.5).to_i graph = "." * 51 graph[25] = ?| graph[p] = ?P graph[e] = ?E graph[g] = ?M print graph, "\n" dd = dd + 1 end print " -------------------------+-------------------------\n\n" end ef='#n8'>8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 
<?xml version='1.0'?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>

<section id="scripts">
  <title>SystemTap Scripts</title>
<indexterm>
<primary>scripts</primary>
<secondary>introduction</secondary>
</indexterm>	
 <indexterm>
<primary>SystemTap scripts</primary>
<secondary>introduction</secondary>
</indexterm> 



<para>
    For the most part, SystemTap scripts are the foundation of each SystemTap
    session. SystemTap scripts instruct SystemTap on what type of information to
    collect, and what to do once that information is collected.
  </para>
<indexterm>
<primary>scripts</primary>
<secondary>introduction</secondary>
<tertiary>components</tertiary>
</indexterm>
<indexterm>
<primary>SystemTap scripts</primary>
<secondary>introduction</secondary>
<tertiary>components</tertiary>
</indexterm>

<indexterm>
	<primary>components</primary>
	<secondary>SystemTap scripts</secondary>
	<tertiary>introduction</tertiary>
</indexterm>

<indexterm>
<primary>scripts</primary>
<secondary>introduction</secondary>
<tertiary>events and handlers</tertiary>
</indexterm>
<indexterm>
<primary>SystemTap scripts</primary>
<secondary>introduction</secondary>
<tertiary>events and handlers</tertiary>
</indexterm>
<indexterm>
<primary>handlers and events</primary>
<secondary>SystemTap scripts</secondary>
<tertiary>introduction</tertiary>
</indexterm>
  <para>
    As stated in <xref linkend="understanding-how-systemtap-works"/>, SystemTap
    scripts are made up of two components: <emphasis>events</emphasis> and
    <emphasis>handlers</emphasis>. Once a SystemTap session is underway,
    SystemTap monitors the operating system for the specified events and
    executes the handlers as they occur.
  </para>

  <note>
    <title>Note</title>
<indexterm>
<primary>scripts</primary>
<secondary>introduction</secondary>
<tertiary>probes</tertiary>
</indexterm>
<indexterm>
<primary>SystemTap scripts</primary>
<secondary>introduction</secondary>
<tertiary>probes</tertiary>
</indexterm>
<indexterm>
<primary>probes</primary>
<secondary>SystemTap scripts</secondary>
<tertiary>introduction</tertiary>
</indexterm>
    <para>
      An event and its corresponding handler is collectively called a
      <emphasis>probe</emphasis>. A SystemTap script can have multiple probes.
    </para>
	
    <para>
      A probe's handler is commonly referred to as a <emphasis>probe
      body</emphasis>.
    </para>
  </note>

  <para>
    In terms of application development, using events and handlers is similar to
    instrumenting the code by inserting diagnostic print statements in a
    program's sequence of commands. These diagnostic print statements allow you
    to view a history of commands executed once the program is run.
  </para>
<!--	<para>
		In terms of application development, using events and handlers is similar to inserting <command>print</command> statements in a program's sequence of commands. These <command>print</command> statements allow you to view a history of commands executed once the program is run. 
	</para>	-->
	
  <para>
    SystemTap scripts allow insertion of the instrumentation code without
    recompilation of the code and allows more flexibility with regard to
    handlers. Events serve as the triggers for handlers to run; handlers can be
    specified to record specified data and print it in a certain manner.
  </para>
	
  <formalpara id="scriptformats">
    <title>Format</title>
<indexterm>
<primary>scripts</primary>
<secondary>introduction</secondary>
<tertiary>format and syntax</tertiary>
</indexterm>
<indexterm>
<primary>SystemTap scripts</primary>
<secondary>introduction</secondary>
<tertiary>format and syntax</tertiary>
</indexterm>
<indexterm>
<primary>format and syntax</primary>
<secondary>SystemTap scripts</secondary>
<tertiary>introduction</tertiary>
</indexterm>
<indexterm>
<primary>syntax and format</primary>
<secondary>SystemTap scripts</secondary>
<tertiary>introduction</tertiary>
</indexterm>
    <para>
      SystemTap scripts use the file extension <filename>.stp</filename>, and
      contains probes written in the following format:
    </para>
  </formalpara>	
<screen>
probe	<replaceable>event</replaceable> {<replaceable>statements</replaceable>}
</screen>

  <para>
    SystemTap supports multiple events per probe; multiple events are delimited
    by a comma (<command>,</command>). If multiple events are specified in a
    single probe, SystemTap will execute the handler when any of the specified
    events occur.
  </para>
<indexterm>
<primary>scripts</primary>
<secondary>introduction</secondary>
<tertiary>statement blocks</tertiary>
</indexterm>  
<indexterm>
<primary>SystemTap scripts</primary>
<secondary>introduction</secondary>
<tertiary>statement blocks</tertiary>
</indexterm>
<indexterm>
<primary>statement blocks</primary>
<secondary>SystemTap scripts</secondary>
<tertiary>introduction</tertiary>
</indexterm>
  <para>
	Each probe has a corresponding <firstterm>statement block</firstterm>. This statement block is 
	enclosed in braces (<command>{ }</command>) and contains the statements to be executed per event. 
	SystemTap executes these statements in sequence; special separators or 
	terminators are generally not necessary between multiple statements.
  </para>

<note>
	<title>Note</title>
	<para>
		Statement blocks in SystemTap scripts follow the same syntax and semantics as the C 
		programming language. A statement block can be nested within another statement block.
  	</para>
</note>	
<indexterm>
<primary>scripts</primary>
<secondary>introduction</secondary>
<tertiary>functions</tertiary>
</indexterm>
<indexterm>
<primary>SystemTap scripts</primary>
<secondary>introduction</secondary>
<tertiary>functions</tertiary>
</indexterm>
<indexterm>
<primary>functions</primary>
<secondary>SystemTap scripts</secondary>
<tertiary>introduction</tertiary>
</indexterm>
  <para>
    Systemtap allows you to write functions to factor out code to be used by a
    number of probes. Thus, rather than repeatedly writing the same 
    series of statements in multiple probes, you can just place the instructions
    in a <firstterm>function</firstterm>, as in:
  </para>

<screen>
function <replaceable>function_name</replaceable>(<replaceable>arguments</replaceable>) {<replaceable>statements</replaceable>}
probe <replaceable>event</replaceable> {<replaceable>function_name</replaceable>(<replaceable>arguments</replaceable>)}
</screen>

  <para>
    The <command><replaceable>statements</replaceable></command> in
    <replaceable>function_name</replaceable> are executed when the probe for
    <replaceable>event</replaceable> executes. The
    <replaceable>arguments</replaceable> are optional values passed into the
    function.
  </para>

<!--
	<para>The <replaceable>exit()</replaceable> condition is optional; this condition safely terminates the session once the script successfully collects the required information the first time.</para>	
	-->
  <important>
    <title>Important</title>
    <para>
      <xref linkend="scripts"/> is designed to introduce readers to the basics
      of SystemTap scripts. To understand SystemTap scripts better, it is
      advisable that you refer to <xref linkend="useful-systemtap-scripts"/>;
      each section therein provides a detailed explanation of the script, its
      events, handlers, and expected output.
    </para>
  </important>

  <section id="systemtapscript-events">
    <title>Event</title>
<indexterm>
<primary>Events</primary>
<secondary>introduction</secondary>
</indexterm>	
    <para>
      SystemTap events can be broadly classified into two types:
      <firstterm>synchronous</firstterm> and
      <firstterm>asynchronous</firstterm>.
    </para>

    <formalpara>
      <title>Synchronous Events</title>
<indexterm>
<primary>Events</primary>
<secondary>synchronous events</secondary>
</indexterm>

<indexterm>
<primary>synchronous events</primary>
<secondary>Events</secondary>
</indexterm>
      <para>
	A <firstterm>synchronous</firstterm> event occurs when any process
	executes an instruction at a particular location in kernel
	code. This gives other events a reference point from which more
	contextual data may be available.
      </para>
    </formalpara>

<!--<para>A <firstterm>synchronous</firstterm> event occurs when any processor executes an instruction matched by the specification. This gives other events a reference point (or instruction address) from which more contextual data may be available.</para>-->

<!--<para>Synchronous events reference particular locations in kernel code. As a result, when synchronous events are used SystemTap can determine contextual  information regarding the location (such as function parameters).</para>-->
<indexterm>
<primary>Events</primary>
<secondary>examples of synchronous and asynchronous events</secondary>
</indexterm>

<indexterm>
<primary>examples of synchronous and asynchronous events</primary>
<secondary>Events</secondary>
</indexterm>
    <para>Examples of synchronous events include:</para>

<variablelist>

<varlistentry>
	<term>syscall.<replaceable>system_call</replaceable></term>
	<listitem>
<indexterm>
<primary>Events</primary>
<secondary><command>syscall.<replaceable>system_call</replaceable></command></secondary>
</indexterm>

<indexterm>
<primary><command>syscall.<replaceable>system_call</replaceable></command></primary>
<secondary>Events</secondary>
</indexterm>

	  <para>
	    The entry to the system call
	    <replaceable>system_call</replaceable>. If the exit from a syscall
	    is desired, appending a <command>.return</command> to the event
	    monitor the exit of the system call instead. For example, to specify
	    the entry and exit of the system call <command>close</command>, use 
	    <command>syscall.close</command> and
	    <command>syscall.close.return</command> respectively.
	  </para>
	</listitem>	
</varlistentry>
	
<varlistentry>
	<term>vfs.<replaceable>file_operation</replaceable></term>
	<listitem>
<indexterm>
<primary>Events</primary>
<secondary><command>vfs.<replaceable>file_operation</replaceable></command></secondary>
</indexterm>

<indexterm>
<primary><command>vfs.<replaceable>file_operation</replaceable></command></primary>
<secondary>Events</secondary>
</indexterm>

	  <para>
	    The entry to the <replaceable>file_operation</replaceable> event for
	    Virtual File System (VFS). Similar to <command>syscall</command>
	    event, appending a <command>.return</command> to the event monitors
	    the exit of the <replaceable>file_operation</replaceable> operation.
	  </para>
	</listitem>	
</varlistentry>
	
<varlistentry>
	<term>kernel.function("<replaceable>function</replaceable>")</term>
	<listitem>
<indexterm>
<primary>Events</primary>
<secondary><command>kernel.function("<replaceable>function</replaceable>")</command></secondary>
</indexterm>

<indexterm>
<primary><command>kernel.function("<replaceable>function</replaceable>")</command></primary>
<secondary>Events</secondary>
</indexterm>
	  <para>
	    The entry to the kernel function
	    <replaceable>function</replaceable>. For example,
	    <command>kernel.function("sys_open")</command> refers to the "event"
	    that occurs when the kernel function <command>sys_open</command> is
	    called by any thread in the system. To specify the
	    <emphasis>return</emphasis> of the kernel function
	    <command>sys_open</command>, append the <command>return</command>
	    string to the event statement;
	    i.e. <command>kernel.function("sys_open").return</command>.
	  </para>
<indexterm>
<primary>Events</primary>
<secondary>wildcards</secondary>
</indexterm>

<indexterm>
<primary>wildcards in events</primary>
</indexterm>
<indexterm>
	<primary>events wildcards</primary>
</indexterm>
	  <para>
	    When defining probe events, you can use asterisk (<literal>*</literal>)
	    for wildcards. You can also trace the entry or exit of a function in
	    a kernel source file. Consider the following example:
	  </para>

<example id="wildcards">
<title>wildcards.stp</title>
<programlisting>
probe kernel.function("*@net/socket.c") { }
probe kernel.function("*@net/socket.c").return { }
</programlisting>	
</example>

	  <remark>Wild cards also work for other types of events, e.g. syscall.*</remark>

	  <para>
	    In the previous example, the first probe's event specifies the entry
	    of ALL functions in the kernel source file
	    <filename>net/socket.c</filename>. The second probe specifies the
	    exit of all those functions. Note that in this example, 
	    there are no statements in the handler;
	    as such, no information will be collected or displayed.
	  </para>
	</listitem>

      </varlistentry>

      <varlistentry>
	<term>kernel.trace("<replaceable>tracepoint</replaceable>")</term>
	<listitem>
<indexterm><primary>tracepoint</primary></indexterm>
<indexterm>
<primary>Events</primary>
<secondary><command>kernel.trace("<replaceable>tracepoint</replaceable>")</command></secondary>
</indexterm>

<indexterm>
<primary><command>kernel.trace("<replaceable>tracepoint</replaceable>")</command></primary>
<secondary>Events</secondary>
</indexterm>
	  <para>
	    The static probe for <replaceable>tracepoint</replaceable>.
	    Recent kernels (2.6.30 and newer)
	    include instrumentation for specific events in the kernel. These
	    events are statically marked with tracepoints.  One example of a
	    tracepoint available in systemtap is
	    <command>kernel.trace("kfree_skb")</command> which indicates each
	    time a network buffer is freed in the kernel.
	  </para>
	</listitem>

      </varlistentry>

      <varlistentry>
	<term>module("<replaceable>module</replaceable>").function("<replaceable>function</replaceable>")</term>
	<listitem>
<indexterm>
<primary>Events</primary>
<secondary><command>module("<replaceable>module</replaceable>")</command></secondary>
</indexterm>

<indexterm>
	<primary><command>module("<replaceable>module</replaceable>")</command></primary>
<secondary>Events</secondary>
</indexterm>
	  <para>Allows you to probe functions within modules. For example:</para>
		
<example id="eventsmodules"><title>moduleprobe.stp</title>
<programlisting>
probe module("ext3").function("*") { }
probe module("ext3").function("*").return { }
</programlisting>	
</example>
		
		<para>
			The first probe in <xref linkend="eventsmodules"/>
		points to the entry of <emphasis>all</emphasis> functions for
		the <filename>ext3</filename> module. The second probe points to
		the exits of all functions for that same module; the use of the
		<command>.return</command> suffix is similar to
		<command>kernel.function()</command>. Note that the probes in
		<xref linkend="eventsmodules"/> do not contain statements
		in the probe handlers, and as such will not print any useful
		data (as in <xref linkend="wildcards"/>).
	        </para>
		
		<para>
			A system's kernel modules are typically located in <filename>/lib/modules/<replaceable>kernel_version</replaceable></filename>, where <replaceable>kernel_version</replaceable> refers to the currently loaded kernel version. Modules use the filename extension <filename>.ko</filename>. 
		</para>	
		
	</listitem>
      </varlistentry>
    </variablelist>

    <formalpara>
      <title>Asynchronous Events</title>
<indexterm>
<primary>Events</primary>
<secondary>asynchronous events</secondary>
</indexterm>

<indexterm>
<primary>asynchronous events</primary>
<secondary>Events</secondary>
</indexterm>

      <para>
	<firstterm>Asynchronous</firstterm> events are not tied to a particular
	instruction or location in code. This family of probe points consists
	mainly of counters, timers, and similar constructs.
      </para>
<!--	<para><firstterm>Asynchronous</firstterm> events, on the other hand, do not point to any reference point. This family of probe points consists mainly of counters, timers, and similar constructs.</para>-->
    </formalpara>

    <para>Examples of asynchronous events include:</para>

    <variablelist>

      <varlistentry>
	<term>begin</term>
	<listitem>
<indexterm>
<primary>Events</primary>
<secondary><command>begin</command></secondary>
</indexterm>

<indexterm>
<primary><command>begin</command></primary>
<secondary>Events</secondary>
</indexterm>		
	  <para>
	    The startup of a SystemTap session; i.e. as soon as the SystemTap
	    script is run.
	  </para>
	</listitem>	
      </varlistentry>	

      <varlistentry>
	<term>end</term>
	<listitem>
<indexterm>
<primary>Events</primary>
<secondary><command>end</command></secondary>
</indexterm>

<indexterm>
<primary><command>end</command></primary>
<secondary>Events</secondary>
</indexterm>
	  <para>The end of a SystemTap session.</para>
	</listitem>	
      </varlistentry>
      <varlistentry>
	<term>timer events</term>
	<listitem>
<indexterm>
<primary>Events</primary>
<secondary>timer events</secondary>
</indexterm>

<indexterm>
<primary>timer events</primary>
<secondary>Events</secondary>
</indexterm>

	  <para>
	    An event that specifies a handler to be executed periodically.
	    For example:
	  </para>
		
<example id="timer"><title>timer-s.stp</title>
<programlisting>
probe timer.s(4)
{
  printf("hello world\n")
}
</programlisting>
</example>

	  <para>
	    <xref linkend="timer"/> is an example of a probe that prints
	    <command>hello world</command> every 4 seconds. Note that you can
	    also use the following timer events:
	  </para>
	
<itemizedlist>
<listitem><para><command>timer.ms(<replaceable>milliseconds</replaceable>)</command></para></listitem>

<listitem><para><command>timer.us(<replaceable>microseconds</replaceable>)</command></para></listitem>

<listitem><para><command>timer.ns(<replaceable>nanoseconds</replaceable>)</command></para></listitem>

<listitem><para><command>timer.hz(<replaceable>hertz</replaceable>)</command></para></listitem>

<listitem><para><command>timer.jiffies(<replaceable>jiffies</replaceable>)</command></para></listitem>
</itemizedlist>

	  <para>
	    When used in conjunction with other probes that collect information,
	    timer events allows you to print out get periodic updates and see
	    how that information changes over time.
	  </para>

	</listitem>
      </varlistentry>

  </variablelist>

    <important>
      <title>Important</title>
      <para>
	SystemTap supports the use of a large collection of probe events. For
	more information about supported events, refer to <command>man
	stapprobes</command>. The <citetitle>SEE ALSO</citetitle> section of
	<command>man stapprobes</command> also contains links to other
	<command>man</command> pages that discuss supported events for specific
	subsystems and components.
      </para>
    </important>

<remark>is reference appropriate? too advanced for readers (it seems so to me)? please advise.</remark> 

  </section>
<!-- stophere -->
<section id="systemtapscript-handler">
	<title>Systemtap Handler/Body</title>
	<indexterm>
		<primary>handlers</primary>
		<secondary>introduction</secondary>
	</indexterm>
	<para> Consider the following sample script: </para>
	
<example id="helloworld"><title>helloworld.stp</title>
<programlisting>
probe begin
{
  printf ("hello world\n")
  exit ()
}
</programlisting>	
</example>
	
	<para>
		In <xref linkend="helloworld"/>, the event <command>begin</command>
		(i.e. the start of the session) triggers the handler enclosed in
		<command>{ }</command>, which simply prints <command>hello
			world</command> followed by a new-line, then exits.
	</para>	
	
	<note>
		<title>Note</title>
		<indexterm>
			<primary>functions (used in handlers)</primary>
			<secondary><command>exit()</command></secondary>
		</indexterm>
		
		<indexterm>
			<primary><command>exit()</command></primary>
			<secondary>functions</secondary>
		</indexterm>
		<para>
			SystemTap scripts continue to run until the
			<command>exit()</command> function executes. If the users wants to stop
			the execution of the script, it can interrupted manually with
			<keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo>.
		</para>
	</note>
	
	<formalpara id="printf">
		<title>printf ( ) Statements</title>
		<indexterm>
			<primary><command>printf()</command></primary>
			<secondary>format strings</secondary>
		</indexterm>
		
		<para>
			The <command>printf ()</command> statement is one of the simplest
			functions for printing data. <command>printf ()</command> can also be
			used to display data using a wide variety of SystemTap functions in the
			following format:
		</para>
	</formalpara>
	
	
	<programlisting>
		printf ("<replaceable>format string</replaceable>\n", <replaceable>arguments</replaceable>)
	</programlisting>
	<indexterm>
		<primary><command>printf()</command></primary>
		<secondary>format strings</secondary>
	</indexterm>
	
	<indexterm>
		<primary>format strings</primary>
		<secondary><command>printf()</command></secondary>
	</indexterm>
	<para>
		The <replaceable>format string</replaceable> specifies how
		<replaceable>arguments</replaceable> should be printed. The format string
		of <xref linkend="helloworld"/> simply instructs SystemTap to print
		<command>hello world</command>, and contains no format specifiers.
	</para>
	<indexterm>
		<primary><command>printf()</command></primary>
		<secondary>format specifiers</secondary>
	</indexterm>
	
	<indexterm>
		<primary>format specifiers</primary>
		<secondary><command>printf()</command></secondary>
	</indexterm>
	<para>
		You can use the format specifiers <command>%s</command> (for strings)
		and <command>%d</command> (for numbers) in format strings, depending on
		your list of arguments. Format strings can have multiple format
		specifiers, each matching a corresponding argument; multiple arguments
		are delimited by a comma (<command>,</command>).
	</para>
	
	<note>
		<title>Note</title>
		<indexterm>
			<primary><command>printf()</command></primary>
			<secondary>syntax and format</secondary>
		</indexterm>
		
		<indexterm>
			<primary>syntax and format</primary>
			<secondary><command>printf()</command></secondary>
		</indexterm>
		<indexterm>
			<primary>format and syntax</primary>
			<secondary><command>printf()</command></secondary>
		</indexterm>
		<para>Semantically, the SystemTap <command>printf</command> function is
			very similar to its C language counterpart. The aforementioned syntax
			and format for SystemTap's <command>printf</command> function is
			identical to that of the C-style <command>printf</command>.
		</para>
	</note>
	
	<para> To illustrate this, consider the following probe example: </para>
	
<example id="syscall-open">
<title>variables-in-printf-statements.stp</title>
<programlisting>
probe syscall.open
{
  printf ("%s(%d) open\n", execname(), pid())
}
</programlisting>
</example>
	
	<para>
		<xref linkend="syscall-open"/> instructs SystemTap to probe all entries to
		the system call <command>open</command>; for each event, it prints the
		current <command>execname()</command> (a string with the executable name) and
		<command>pid()</command> (the current process ID number), followed by the word
		<command>open</command>. A snippet of this probe's output would look like:
	</para>
	
	<remark>editorial review: does a clarification that "format specifier1" is
		to "argument1", "format specifier2" is to "argument2", or is this clear
		enough? </remark>
	
<screen>
vmware-guestd(2206) open
hald(2360) open
hald(2360) open
hald(2360) open
df(3433) open
df(3433) open
df(3433) open
hald(2360) open
</screen>
	
	<formalpara id="systemtapscript-functions">
		<title>SystemTap Functions</title>
		<indexterm>
			<primary>functions</primary>
		</indexterm>
		
		<indexterm>
			<primary>SystemTap script functions</primary>
		</indexterm>
		
		<indexterm>
			<primary>handler functions</primary>
		</indexterm>
		
		<para>
			SystemTap supports a wide variety of functions that can be used as
			<command>printf ()</command> arguments. <xref linkend="syscall-open"/>
			uses the SystemTap functions <command>execname()</command> (name of the
			process that called a kernel function/performed a system call) and
			<command>pid()</command> (current process ID).
		</para>
	</formalpara>		
	
	<remark>is "handler function" an appropriate term? wcohen: use "SystemTap functions" to match up language in man pages</remark>
	
	<para>The following is a list of commonly-used SystemTap functions:</para>	
	<variablelist>
		
		<varlistentry>
			<term>tid()</term>
			<listitem>
				<indexterm>
					<primary>functions</primary>
					<secondary><command>tid()</command></secondary>
<!-- 					<tertiary><command>tid()</command></tertiary> -->
				</indexterm>
				
				<indexterm>
					<primary>functions</primary>
					<secondary><command>tid()</command></secondary>
<!-- 					<tertiary></tertiary> -->
				</indexterm>
				
				<indexterm>
					<primary><command>tid()</command></primary>
					<secondary>functions</secondary>
<!-- 					<tertiary>handler </tertiary> -->
				</indexterm>
				
				<para>The ID of the current thread.</para>
			</listitem>	
		</varlistentry>	
		
		<varlistentry>
			<term>uid()</term>
			<listitem>
				<indexterm>
					<primary>functions</primary>
					<!--<secondary>handler functions</secondary>-->
					<secondary><command>uid()</command></secondary>
				</indexterm>
<!--				
				<indexterm>
					<primary>handler functions</primary>
					<secondary>Handlers</secondary>
					<tertiary><command>uid()</command></tertiary>
				</indexterm>
				-->
				<indexterm>
					<primary><command>uid()</command></primary>
					<secondary>functions</secondary>
<!-- 					<tertiary>handler functions</tertiary> -->
				</indexterm>
				<para>The ID of the current user.</para>
			</listitem>	
		</varlistentry>
		
		<varlistentry>
			<term>cpu()</term>
			<listitem>
				<indexterm>
					<primary>functions</primary>
					<!--<secondary>handler functions</secondary>-->
					<secondary><command>cpu()</command></secondary>
				</indexterm>
<!--				
				<indexterm>
					<primary>handler functions</primary>
					<secondary>Handlers</secondary>
					<tertiary><command>cpu()</command></tertiary>
				</indexterm>
				-->
				<indexterm>
					<primary><command>cpu()</command></primary>
					<secondary>functions</secondary>
<!-- 					<tertiary>handler functions</tertiary> -->
				</indexterm>		
				<para>The current CPU number.</para>
			</listitem>	
		</varlistentry>
		
		<varlistentry>
			<term>gettimeofday_s()</term>
			<listitem>
				<indexterm>
					<primary>functions</primary>
					<!--<secondary>handler functions</secondary>-->
					<secondary><command>gettimeofday_s()</command></secondary>
				</indexterm>
<!--				
				<indexterm>
					<primary>handler functions</primary>
					<secondary>Handlers</secondary>
					<tertiary><command>gettimeofday_s()</command></tertiary>
				</indexterm>
				-->
				<indexterm>
					<primary><command>gettimeofday_s()</command></primary>
					<secondary>functions</secondary>
<!-- 					<tertiary>handler functions</tertiary> -->
				</indexterm>
				
				<para>The number of seconds since UNIX epoch (January 1, 1970).</para>
			</listitem>	
		</varlistentry>
		
		<varlistentry>
			<term>ctime()</term>
			<listitem>
				<indexterm>
					<primary>functions</primary>
					<!--<secondary>handler functions</secondary>-->
					<secondary><command>ctime()</command></secondary>
				</indexterm>
<!--				
				<indexterm>
					<primary>handler functions</primary>
					<secondary>Handlers</secondary>
					<tertiary><command>ctime()</command></tertiary>
				</indexterm>
				-->
				<indexterm>
					<primary><command>ctime()</command></primary>
					<secondary>functions</secondary>
<!-- 					<tertiary>handler functions</tertiary> -->
				</indexterm>				
				<para>
					Convert number of seconds since UNIX epoch to date.
				</para>
			</listitem>	
		</varlistentry>
		
		<!--
		    <varlistentry>
			    <term>get_cycles()</term>
			    <listitem>
				    <para>A snapshot of the hardware cycle counter.</para>
			    </listitem>	
		    </varlistentry>
		    -->
		    
		    <varlistentry>
			    <term>pp()</term>
			    <listitem>
				    <indexterm>
					    <primary>functions</primary>
					    <!--<secondary>handler functions</secondary>-->
					    <secondary><command>pp()</command></secondary>
				    </indexterm>
<!--				    
				    <indexterm>
					    <primary>handler functions</primary>
					    <secondary>Handlers</secondary>
					    <tertiary><command>pp()</command></tertiary>
				    </indexterm>
				    -->
				    <indexterm>
					    <primary><command>pp()</command></primary>
					    <secondary>functions</secondary>
<!-- 					    <tertiary>handler functions</tertiary> -->
				    </indexterm>
				    <para>A string describing the probe point currently being handled.</para>
			    </listitem>	
		    </varlistentry>
		    <!-- removed, doesnt work as expected anymore
			 <varlistentry>
				 <term>probefunc()</term>
				 <listitem>
					 <para>If known, the name of the function in which the probe was placed.</para>
				 </listitem>	
			 </varlistentry>
			 -->
			 
			 <varlistentry>
				 <term>thread_indent()</term>
				 <listitem>
					 <indexterm>
						 <primary>functions</primary>
						 <!--<secondary>handler functions</secondary>-->
						 <secondary><command>thread_indent()</command></secondary>
					 </indexterm>
<!--					 
					 <indexterm>
						 <primary>handler functions</primary>
						 <secondary>Handlers</secondary>
						 <tertiary><command>thread_indent()</command></tertiary>
					 </indexterm>
					 -->
					 <indexterm>
						 <primary><command>thread_indent()</command></primary>
						 <secondary>functions</secondary>
<!-- 						 <tertiary>handler functions</tertiary> -->
					 </indexterm>
					 <para>
						 This particular function is quite useful, providing you with a way
						 to better organize your print results. The function takes one
						 argument, an indentation delta, which indicates how many
						 spaces to add or remove from a thread's "indentation counter".
						 It then returns a
						 string with some generic trace data along with an appropriate number
						 of indentation spaces.
					 </para>
					 
					 <para>
						 The generic data included in the returned string includes a
						 timestamp (number of microseconds since the 
						 first call to <command>thread_indent()</command> by the thread),
						 a process name, and the thread ID. This allows you to
						 identify what functions were called, who called them, and the
						 duration of each function call.
					 </para>	
					 
					 <para>
						 If call entries and exits immediately precede each other, it is easy
						 to match them. However, in most cases, after a first function call
						 entry is made several other call entries and exits may be made
						 before the first call exits. The indentation counter helps you match
						 an entry with its corresponding exit by indenting the next function
						 call if it is not the exit of the previous one.
					 </para>
					 
					 <para>
						 Consider the following example on the use of
						 <command>thread_indent()</command>:
					 </para>
					 
<example id="thread_indent"><title>thread_indent.stp</title>
<programlisting>
probe kernel.function("*@net/socket.c") 
{
  printf ("%s -> %s\n", thread_indent(1), probefunc())
}
probe kernel.function("*@net/socket.c").return 
{
  printf ("%s &lt;- %s\n", thread_indent(-1), probefunc())
}
</programlisting>
</example>
					 
					 <para>
						 <xref linkend="thread_indent"/> prints out the
						 <command>thread_indent()</command> and probe functions at each event
						 in the following format:</para>
					 
<screen>
0 ftp(7223): -&gt; sys_socketcall
1159 ftp(7223):  -&gt; sys_socket
2173 ftp(7223):   -&gt; __sock_create
2286 ftp(7223):    -&gt; sock_alloc_inode
2737 ftp(7223):    &lt;- sock_alloc_inode
3349 ftp(7223):    -&gt; sock_alloc
3389 ftp(7223):    &lt;- sock_alloc
3417 ftp(7223):   &lt;- __sock_create
4117 ftp(7223):   -&gt; sock_create
4160 ftp(7223):   &lt;- sock_create
4301 ftp(7223):   -&gt; sock_map_fd
4644 ftp(7223):    -&gt; sock_map_file
4699 ftp(7223):    &lt;- sock_map_file
4715 ftp(7223):   &lt;- sock_map_fd
4732 ftp(7223):  &lt;- sys_socket
4775 ftp(7223): &lt;- sys_socketcall
</screen>
					 
					 <para>This sample output contains the following information:</para>
					 
					 <itemizedlist>
						 <listitem><para>The time (in microseconds) since the initial <command>thread_ident()</command> call for the thread (included in the string from <command>thread_ident()</command>).</para></listitem>
						 
						 <listitem><para>The process name (and its corresponding ID) that made the function call (included in the string from <command>thread_ident()</command>).</para></listitem>
						 
						 <listitem><para>An arrow signifying whether the call was an entry (<computeroutput>&lt;-</computeroutput>) or an exit (<computeroutput>-></computeroutput>); the indentations help you match specific function call entries with their corresponding exits.</para></listitem>
						 
						 <listitem><para>The name of the function called by the process.</para></listitem>
					 </itemizedlist>	
					 
					 <remark>remember to add a reference later to "tapsets" from here, to clarify
						 that thread_indent is defined in tapsets as a special function of sorts</remark>
					 
				 </listitem>	
			 </varlistentry>
			 
			 <varlistentry>
				 <term>name</term>
				 <listitem>
<indexterm>
<primary>local variables</primary>
<secondary>name</secondary>
</indexterm>

<indexterm>
<primary>variables (local)</primary>
<secondary>name</secondary>
</indexterm>

<indexterm>
<primary>name</primary>
<secondary>local variables</secondary>
</indexterm>					 
<!--					 <indexterm>
						 <primary>functions</primary>
						 <secondary>handler functions</secondary>
						 <tertiary><command>name</command></tertiary>
					 </indexterm>
					 
					 <indexterm>
						 <primary>handler functions</primary>
						 <secondary>Handlers</secondary>
						 <tertiary><command>name</command></tertiary>
					 </indexterm>
					 
					 <indexterm>
						 <primary><command>name</command></primary>
						 <secondary>Handlers</secondary>
						 <tertiary>handler functions</tertiary>
					 </indexterm>-->
					 <para>Identifies the name of a specific system call. This variable can
						 only be used in probes that use the event
						 <command>syscall.<replaceable>system_call</replaceable></command>.
					 </para>
				 </listitem>	
			 </varlistentry>
			 
			 <varlistentry>
				 <term>target()</term>
				 <listitem>
					 
					 <indexterm>
						 <primary>functions</primary>
<!-- 						 <secondary>handler functions</secondary> -->
						 <secondary><command>target()</command></secondary>
					 </indexterm>
<!--					 
					 <indexterm>
						 <primary>handler functions</primary>
						 <secondary>Handlers</secondary>
						 <tertiary><command>target()</command></tertiary>
					 </indexterm>
					 -->
					 <indexterm>
						 <primary><command>target()</command></primary>
						 <secondary>functions</secondary>
<!-- 						 <tertiary>handler functions</tertiary> -->
					 </indexterm>
					 <para>
						 Used in conjunction with <command>stap
							 <replaceable>script</replaceable> -x <replaceable>process
								 ID</replaceable></command> or <command>stap
							 <replaceable>script</replaceable> -c
							 <replaceable>command</replaceable></command>. If you want to specify
						 a script to take an argument of a process ID or command, use
						 <command>target()</command> as the variable in the script to refer
						 to it. For example:
					 </para>
					 
<example id="targetexample">
<title>targetexample.stp</title>
<programlisting>
probe syscall.* {
  if (pid() == target())
    printf("%s/n", name)
}	
</programlisting>
</example>
					 
					 <para>
						 When <xref linkend="targetexample"/> is run with the argument
						 <command>-x <replaceable>process ID</replaceable></command>, it
						 watches all system calls (as specified by the event
						 <command>syscall.*</command>) and prints out the name of all system
						 calls made by the specified process.
					 </para>
					 
					 <para>
						 This has the same effect as specifying <command>if (pid() ==
							 <replaceable>process ID</replaceable>)</command> each time you wish
						 to target a specific process. However, using
						 <command>target()</command> makes it easier for you to re-use the
						 script, giving you the ability to simply pass a process ID as an
						 argument each time you wish to run the script (e.g. <command>stap
							 targetexample.stp -x <replaceable>process ID</replaceable></command>).
					 </para>
					 <!--		
							<note>
								<title>Note</title>
								<para>In <xref linkend="targetexample"/>, <command>name</command> instructs SystemTap to capture the name of the process</para>
							</note>	-->
							
						</listitem>
					</varlistentry>
					
					<!--	
						<varlistentry>
							<term></term>
							<listitem>
								<para></para>
							</listitem>	
						</varlistentry>
						-->	
					</variablelist>		
					
					<para>For more information about supported SystemTap functions, refer to
						<command>man stapfuncs</command>.
					</para>
					
					<remark>will need a complete listing of supported handler functions? also, SystemTap function descriptions seem ambiguous, please advise.</remark>
					
					<!--	
						<para>
							<replaceable>variable</replaceable> can be either <command>%s</command> for strings, or <command>%d</command> for numbers, depending on the <replaceable>handler function</replaceable> used. Each <command>printf ()</command> statement can contain multiple <replaceable>variable</replaceable>s, with each one corresponding to a matching <replaceable>handler function</replaceable>. Multiple <replaceable>handler function</replaceable>s are delimited by comma (<command>,</command>). 
						</para>	
						
						<command>printf ()</command> is a SystemTap-supported C statement, and can also trap data using a wide variety
						
						SystemTap supports a wide variety of handler functions that can trap data when triggered by events. One way to display these functions is to use the <command>print()</command>   
					</para>	
					
					
					<para>
						<xref linkend="wildcards"/> illustrates an example of a SystemTap script that contains no handlers. SystemTap will still be able to run the script, but no information will be displayed. 	
					</para>
					-->
					
  </section>
</section>
generated by cgit (git 2.34.1) at 2025-08-07 04:55:15 +0000