A apresentação de Yonghong Song tratou da agradabilidade do desenvolvimento de aplicações BPF. Existem dois arcabouços (frameworks) para o desenvolvimento de programas BPF: bcc (BPF Compiler Collection) e libbpf-tools. O bcc foi o primeiro disponível para isso, então ainda muito utilizado. No entanto, ele não é mais a forma recomendada para desenvolvimento de aplicações BPF. Assim, devemos focar no libbpf.

Na apresentação BPF Observability tools update, por Brendan Gregg, um tópico que foi abordado foi o desempenho dos user probes (uprobe). Isso muito nos interessa, porque é o calcanhar de Aquiles ao usar BPF com programas em Java.

Na apresentação BPF Guidelines for newcomers, também por Brendan Gregg, temos diretivas para uso do BPF: https://tinyurl.com/bpfguidelines2022 (ou https://docs.google.com/document/d/1pzkUqyQU65V0WIukqK4EU_u3f8h35i-ddORI9WbYatw).

A palestra de Guillaume Tucker sobre testes no Kernel do Linux propõe que o desenvolvimento e lançamento de novas versões do kernel sejam dirigidas a testes automatizados (vídeo disponível em https://youtu.be/v--rVT4RsCE?t=15731). Atualmente temos uma infraestrutura razoável para teste: KUnit para escrita de testes de unidade; LTP e kselftest. No entanto, os resultados das atividades de teste são restritas a poucos desenvolvedores (geralmente os responsáveis pelos subsistemas) e não são amplamente compartilhados. Algumas ferramentas que atualmente disponibilizam os resultados das atividades de teste são: syzbot, KernelCI, RedHat CKI, regzbot. No entanto, é necessário deixar os testes mais claros para o desenvolvimento. Várias sugestões foram feitas nesse sentido: incluir os casos de teste com o código do Kernel do Linux (hoje são mantidos separadamente); incluir na mensagem de commit informações sobre a execução de casos de teste (quem executou e onde estão disponíveis os resultados).

Ainda da turma de BPF, descobri que o acme (Arnaldo Carvalho de Melo, ex-Conectiva) está trabalhando com isso agora.