Eu tenho a fonte para o Linux 2.6.27.8 à mão, pois estou desenvolvendo o driver no momento em um destino ARM incorporado.
O arquivo ... linux-2.6.27.8-lpc32xx/net/ipv4/raw.c
na linha 934 contém, por exemplo
seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
" %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p %d\n",
i, src, srcp, dest, destp, sp->sk_state,
atomic_read(&sp->sk_wmem_alloc),
atomic_read(&sp->sk_rmem_alloc),
0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));
quais saídas
[wally@zenetfedora ~]$ cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 017AA8C0:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 15160 1 f552de00 299
1: 00000000:C775 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 13237 1 f552ca00 299
...
na função raw_sock_seq_show()
que faz parte de uma hierarquia de funções de manipulação de procfs . O texto não é gerado até que read()
seja feito um pedido do /proc/net/tcp
arquivo, um mecanismo razoável, pois as leituras do procfs são certamente muito menos comuns do que atualizar as informações.
Alguns drivers (como o meu) implementam a função proc_read com um único sprintf()
. A complicação extra na implementação dos drivers principais é lidar com saídas potencialmente muito longas que podem não caber no buffer intermediário do espaço do kernel durante uma única leitura.
Eu testei isso com um programa usando um buffer de leitura de 64K, mas ele resulta em um buffer de espaço do kernel de 3072 bytes no meu sistema para proc_read retornar dados. São necessárias várias chamadas com ponteiros avançados para obter mais do que a quantidade de texto retornada. Não sei qual o caminho certo para tornar os dados retornados consistentes quando mais de uma E / S é necessária. Certamente cada entrada /proc/net/tcp
é auto-consistente. Há alguma probabilidade de que as linhas lado a lado sejam instantâneas em momentos diferentes.