Sources Bugzilla – Bug 2035
investigate boot-time probing
Last modified: 2008-04-30 17:26:33 UTC
Action item from face-to-face meeting. The task is to investigate the following idea, to estimate effort required to implement it. Idea: make it possible to link in a systemtap probe module, perhaps statically, into the kernel, for execution early during boot time. In contrast with the usual behavior, this would likely require the module to *not* rely on stpd chitchat in order to register and activate probes. Likewise, it may be appropriate to use normal module unload hooks to unregister / clean up. I/O early during boot is of course tricky. Perhaps the runtime could buffer a large amount of data in procfs-bound buffers, even before a user-level process comes along, opens procfs and pulls the data out. Perhaps the runtime could flush buffered data to printk if no user-space program comes along by the time it's time to shut down. When complete, this work might allow stpd to be partially deprecated, by using the module-init / module-exit hooks for normal operations, and something as simple as "cat" to fetch probe output (procfs) data.
Subject: Re: New: investigate boot-time probing On Mon, 2005-12-12 at 20:04 +0000, fche at redhat dot com wrote: > Action item from face-to-face meeting. The task is to investigate the following > idea, to estimate effort required to implement it. > > Idea: make it possible to link in a systemtap probe module, perhaps statically, > into the kernel, for execution early during boot time. So we generate a module, run mkinitrd and reboot. Problems with that are 1. IO and 2. we can't proble into modules because we don't know their addreses. That is why this is dependson 1145. The IO solution is likely going to be the same as what I am working on for another problem. (need BZ) I am playing with support for network IO and want to also look at serial ports. This would be for uses like in a flight data recorder where we need data right up to the moment the system crashes. The cost of this approach is likely to be some flexibility and performance. > When complete, this work might allow stpd to be partially deprecated, by using > the module-init / module-exit hooks for normal operations, and something as > simple as "cat" to fetch probe output (procfs) data. That is a strange goal. Do you have some reason for it?
(In reply to comment #1) > > > When complete, this work might allow stpd to be partially deprecated [...] > That is a strange goal. Do you have some reason for it? Nothing deep or urgent, just desiderata like the reduction in number of interacting components.
Dan Berrange mentioned that he has developed some techniques to do boot probes. The following is the link to his people page with the information: http://people.redhat.com/berrange/systemtap/bootprobe/
Berrange's method is simple & neat, and may be good enough for some users. My guess is that we will still need something initrd-based & stpd-less, for those who need to deal with debugging of device drivers, kernel initialization, and the like.
(In reply to comment #4) > My guess is that we will still need something initrd-based & stpd-less, for > those who need to deal with debugging of device drivers, kernel initialization, > and the like. I'm still interested in this feature for debugging initialization bugs of device drivers. Sometimes those bugs can not be reproduced or randomly happen, so I think initrd-based tracing is very helpful. Fortunately, we already have attach/detach feature(bz3857) and crash extension, so I/O is not a problem.