I have been analysing how a Linux USB driver works using two disparate methods:
- examining the output of
usbmon
, which is a hex dump-ish view of what's being sent "on the wire". - adding
printk()
statements to the kernel driver module source and reloading it into the kernel.
The output of these methods is available to me through cat /sys/kernel/debug/usb/usbmon/1u
and cat /var/log/kern.log
respectively.
What I would now like to now do is merge these two files in real-time, so I can see the printk()
logging messages I have inserted into the kernel driver interleaved with the lines of hex being sent across the wire. For example, I might put a printk()
statement at the beginning and end of a piece of driver code that I know sends USB data, and I want to be able to view the hex (from usbmon
that got sent in between, e.g.
Entering function sendImportantUSBData() // from driver code printk()
0a ff bbbb ac 0993 b3332 // from usbmon log
Exiting function sendImportantUSBData() // from driver code printk()
I know tail
can show the last n
lines of a single file. I also know that the tool multitail
can do some merging, though I didn't see any relevant details regarding timing sensitivity and what effect it has on merge line order accuracy. Is there an appropriate tool for what I have described that either a)
does accurate merging of time-sensitive logs or b)
allows one to specify a relatively small time interval for when merging should be done? In the latter case, I can probably insert sleep statements into the driver code at critical points to make sure the merging tool has time to read my printk()
output before the driver moves onto the next USB transaction which would generate further hex from usbmon
.
multitail
has few relevant flags:--mergeall
, and-ts
As for enforcing time coherence, I've done it once, but it had to be done by every log line having a timestamp, and then wrote an awk script to rearrange the entries to be sorted by time. That's nowhere near real-time. The lesson learned on that one was that the timestamps had to be generated by the program generating them, and not the logger program, as they tend to be heavily buffered, which demolishes any notion of decent timestamping. – Marcin Sep 06 '12 at 13:59