7

Has anyone tried to create a log file of interprocess communications? Could someone give me a little advice on the best way to achieve this?

Patrick
  • 71
  • 1
  • What kind of communication? TCP sockets? Unix sockets? DBUS? Shared memory? – thejh Nov 06 '10 at 12:44
  • Thanks guys. Actually I don't know! I want to change one interface card for another. I was hoping to log the API calls to the original driver and analyze the output to understand the ins and outs of it and then to translate this to the API of another card – Patrick Nov 06 '10 at 12:50
  • Network card control isn't IPC, it is inside the kernel. – thejh Nov 06 '10 at 12:58
  • Hi thejh, thanks. This is actually a GPIB card it's used with scientific instruments but you are absolutely right, it's probably in the kernel. Could you help me rephrase my question? Should I just say "how do I log communication to a kernel driver"? Thanks again! – Patrick Nov 06 '10 at 13:02
  • I'm not a kernel expert, but I would rephrase the question to what you proposed. – thejh Nov 06 '10 at 13:12
  • whoops, that's "thanks" and I was just wondering if anyone can recommend the best way to do this? Can I kill my own thread before reposting – Patrick Nov 06 '10 at 13:33
  • @Patrick, you should find a `close` below your tags...to close a question – st0le Nov 13 '10 at 18:05
  • IPC is also in the kernel, it's just that network communication is not generally considered IPC. – Matt Joiner Mar 17 '11 at 02:14

3 Answers3

2

The question is not quite clear, and comments make it less clear, but anyway...

The two things to try first are ipcs and strace -e trace=ipc.

horsh
  • 2,670
  • 16
  • 32
1

If you want to log all IPC(seems very intensive), you should consider instrumentation.

Their are a lot of good tools for this, check out PIN in perticular, this section of the manual;

In this example, we show how to do more selective instrumentation by examining the instructions. This tool generates a trace of all memory addresses referenced by a program. This is also useful for debugging and for simulating a data cache in a processor.

If your doing some heavy weight tuning and analysis, check out TAU (Tuning and analysis utilitiy).

RandomNickName42
  • 5,721
  • 1
  • 32
  • 33
1

Communication to a kernel driver can take many forms. There is usually a special device file for communication, or there can be a special socket type, like NETLINK. If you are lucky, there's a character device to which read() and write() are the sole means of interaction - if that's the case then those calls are easy to intercept with a variety of methods. If you are unlucky, many things are done with ioctls or something even more difficult.

However, running 'strace' on the program using the kernel driver to communicate can reveal just about all it does - though 'ltrace' might be more readable if there happens to be libraries the program uses for communication. By tuning the arguments to 'strace', you can probably get a dump which contains just the information you need:

  • First, just eyeball the calls and try to figure out the means of kernel communication
  • Then, add filters to strace call to log only the kernel communication calls
  • Finally, make sure strace logs the full strings of all calls, so you don't have to deal with truncated data

The answers which point to IPC debugging probably are not relevant, as communicating with the kernel almost never has anything to do with IPC (atleast not the different UNIX IPC facilities).

Nakedible
  • 3,817
  • 7
  • 30
  • 39