Differences between revisions 4 and 5
Revision 4 as of 2007-04-27 13:41:18
Size: 1896
Editor: FChE
Revision 5 as of 2008-01-10 19:47:35
Size: 1900
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
attachment:printk-time-toggle.stp [[attachment:printk-time-toggle.stp]]

Unfixed boot parameters


Sometimes, one changes one's mind about the preferred kernel boot options, even after the kernel is already running. Case in point: the "time" option, which makes printk messages also print a timestamp. If you boot without "time", you can't get it later. Or can you?



probe begin {
  printf ("Waiting for someone to call printk\n")
probe kernel.function("printk") {
  $printk_time = ! $printk_time
  printf ("Toggled $printk_time: %s\n", $printk_time ? "on" : "off")

Note that we can't just toggle $printk_time in a begin probe, since it is not visible in that context. It is only accessible to a probe in the same compilation unit. Thus the probe on printk itself, and the need to wait for it to be hit.


# dmesg | tail -1
..... (no time stamp)
# printk-time-toggle.stp
Waiting for someone to call printk
Toggled $printk_time: on
# dmesg | tail -1
[928342.278342] ...... (time stamp)


Many such parameters are changeable at run-time. Guru mode is required.

It is a bit inconvenient to have to put a probe on printk to get access to the $printk_time variable. It's a static value that is only in scope of some function in the same compilation unit, and systemtap does not expose variables to script that are not also available to a C routine in the same context. Perhaps this could be relaxed.

The script could trigger its own printk instead of waiting for someone else. Since it's already a guru-mode script, and printk is safe from a begin probe, the script could have included a little embedded-C snippet to call printk from the begin probe.


None: WSprintkBootParams (last edited 2008-01-10 19:47:35 by localhost)