2010-11-06 6 views
7

Qualcuno ha provato a creare un file di registro delle comunicazioni tra processi? Qualcuno potrebbe darmi un piccolo consiglio sul modo migliore per raggiungere questo obiettivo?Comunicazioni interprocess snoop

+0

Che tipo di comunicazione? Socket TCP? Prese Unix? DBUS? Memoria condivisa? – thejh

+0

Quale tipo di IPC? – st0le

+0

Grazie ragazzi. In realtà non lo so! Voglio cambiare una scheda di interfaccia con un'altra. Speravo di registrare le chiamate API al driver originale e analizzare l'output per comprenderne i dettagli e poi tradurlo nell'API di un'altra scheda. – Patrick

risposta

2

La questione non è del tutto chiaro, e le osservazioni rendono meno chiara, ma comunque ...

Le due cose da provare prima sono ipcs e strace -e trace=ipc.

+0

buoni strumenti. Non mi è chiaro però come useresti ipcs. – fabrizioM

1

Se si desidera registrare tutto l'IPC (sembra molto intenso), è necessario considerare la strumentazione.

Loro sono un sacco di buoni strumenti per questo, controlla PIN in pericolare, this section del manuale;

In questo esempio, mostriamo come fare strumentazione più selettivo dalle esaminando le istruzioni. Questo strumento genera una traccia di tutti gli indirizzi di memoria a cui fa riferimento un programma. Questo è utile anche per il debug e per simulare una cache di dati in un processore .

Se il vostro fare qualche messa a punto pesante e di analisi, check out TAU (sintonizzazione e l'analisi utilitiy).

1

La comunicazione con un driver del kernel può assumere molte forme. Di solito c'è un file di dispositivo speciale per la comunicazione, oppure può esserci un tipo di socket speciale, come NETLINK. Se sei fortunato, c'è un dispositivo di carattere in cui read() e write() sono l'unico mezzo di interazione - se questo è il caso, quelle chiamate sono facili da intercettare con una varietà di metodi. Se sei sfortunato, molte cose sono fatte con ioctl o qualcosa di ancora più difficile.

Tuttavia, eseguire 'strace' sul programma utilizzando il driver del kernel per comunicare può rivelare quasi tutto ciò che fa, anche se 'ltrace' potrebbe essere più leggibile se ci sono librerie che il programma usa per la comunicazione. Sintonizzando gli argomenti a 'strace', probabilmente si può ottenere un dump che contiene solo le informazioni necessarie:

  • In primo luogo, solo bulbo oculare le chiamate e cercare di capire i mezzi di comunicazione kernel
  • Poi, aggiungere filtri per strace chiamare per registrare solo la comunicazione kernel chiama
  • Infine, assicurarsi strace registra le stringhe complete di tutte le chiamate, in modo da non avere a che fare con i dati troncati

le risposte che puntano a Il debugging dell'IPC probabilmente non è rilevante, in quanto comunicare con il kernel non ha quasi mai nulla a che fare con IPC (almeno non con le diverse strutture IPC UNIX).

Problemi correlati