Bonjour,
J'ai eu un peu plus le temps de me pencher sur le code, et du coup, en lisant un ou deux tutos, j'ai compris comment ça marchait et l'API netlink process connector + bpf correspondent parfaitement au besoin que j'avais. Donc encore merci beaucoup, j'ai appris pas mal de trucs…
Par contre, d'après la page de man netlink 7 :
"If a process owns several netlink sockets, then nl_pid can only be equal to the process ID for at most one socket."
du coup, le
89 hdr->nlmsg_pid = getpid();
est problématique pour être utilisé dans une lib. En effet, rien n'indique qu'une autre socket netlink n'est pas utilisée ailleurs dans le programme, ce qui devrait provoquer un EADDRINUSE au bind ou un truc du genre…
De ce que j'ai vu, il semble ce genre de problème se soit posé pour les développeurs de la libnl.
Du coup, personnellement j'utilise hdr->nlmsg_pid = 0, qui laisse au kernel le choix du nl_pid.
D'ailleurs, je ne comprends pas pourquoi il est laissé au développeur, la possibilité de choisir ce nl_pid, puisque ça ne semble servir qu'à générer des bugs…
# Merci
Posté par ncarrier . En réponse au journal wait4: attendre la fin d’un ou plusieurs processus quelconques. Évalué à 1.
Bonjour,
J'ai eu un peu plus le temps de me pencher sur le code, et du coup, en lisant un ou deux tutos, j'ai compris comment ça marchait et l'API netlink process connector + bpf correspondent parfaitement au besoin que j'avais. Donc encore merci beaucoup, j'ai appris pas mal de trucs…
Par contre, d'après la page de man netlink 7 :
"If a process owns several netlink sockets, then nl_pid can only be equal to the process ID for at most one socket."
du coup, le
89 hdr->nlmsg_pid = getpid();
est problématique pour être utilisé dans une lib. En effet, rien n'indique qu'une autre socket netlink n'est pas utilisée ailleurs dans le programme, ce qui devrait provoquer un EADDRINUSE au bind ou un truc du genre…
De ce que j'ai vu, il semble ce genre de problème se soit posé pour les développeurs de la libnl.
Du coup, personnellement j'utilise hdr->nlmsg_pid = 0, qui laisse au kernel le choix du nl_pid.
D'ailleurs, je ne comprends pas pourquoi il est laissé au développeur, la possibilité de choisir ce nl_pid, puisque ça ne semble servir qu'à générer des bugs…