Assim, inicialmente, o processo A criou um arquivo contendo dados (37 Bytes) lidos de um fluxo (UART).
O processo B precisa adquirir esses dados, que são armazenados em / dev / shm.
O processo A tem um máximo absoluto de 4 ms para gravar esse arquivo. Exceder isso resulta em perda de dados inaceitável. A criação do arquivo leva uma média de 600us, o que é perfeitamente bom, não aumentaria aleatoriamente para 7ms ou mais.
Para evitar o manuseio de arquivos, eu queria acessar a RAM diretamente, passando o endereço da matriz como startparameter:
// Process A
sprintf(cmd, "path_to_file.out %i", (unsigned int)&rx_buffer);
system(cmd);
// Process B
int rx_buffer_address = atoi(argv[1]);
Usando o procedimento sugerido por Gilles , consegui ler uma vez
sprintf(mem_file_name, "/proc/%d/mem", pid);
mem_fd = open(mem_file_name, O_RDONLY);
ptrace(PTRACE_ATTACH, pid, NULL, NULL);
waitpid(pid, NULL, 0);
lseek(mem_fd, offset, SEEK_SET);
read(mem_fd, buf, _SC_PAGE_SIZE);
ptrace(PTRACE_DETACH, pid, NULL, NULL);
A execução dessa abordagem falha repetidamente na segunda tentativa com open () retornando ENOENT (Nenhum tal arquivo ou dir) e ptrace retornando ESRCH (Nenhum tal processo), mesmo ao adicionar close (mem_fd) à função.
Outras investigações mostraram que a primeira chamada PTRACE_DETACH já retorna ESRCH.
Olhando para cima ptrace () , eu tentei ler a memória com PTRACE_PEEKDATA, que retorna 0xFF para cada leitura.
A região acessada pelo método PEEKDATA é mapeada de maneira diferente do descritor de arquivo / mem? Ou estou faltando alguma coisa sobre os dois métodos ou até mesmo os tempos de acesso ao arquivo spiking?