This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
Hi - > We really need to start getting the kernel <-> user space data transport > code into the runtime library soon. [...] (At some point, you'll also need to address the posted concerns about the runtime code already committed.) > 1. High-speed transfer of large amounts of collected data. [...] It would be helpful if you outlined end-to-end usage scenarios for such a data path. Are you only talking about a script-level function call to replace printk()? Are you talking about asynchronous global-variable snapshots as per the old /proc code? Do you imagine that result dumps would generally come from explicitly scripted trace calls during systemtap probe shutdown? > 2. A separate channel for immediate messages. Used to signal error > conditions, print warnings, etc. Anything that is not normal trace > output. If such "health" status data was routinely inserted into the normal data stream, would a second such stream be necessary? - FChE
Attachment:
pgp00000.pgp
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |