1.. SPDX-License-Identifier: GPL-2.0 2 3===================================== 4Subsistema de Rede do Linux (netdev) 5===================================== 6 7tl;dr 8----- 9 10- **Direcione seu patch para uma árvore** – use ``[PATCH net]``para correções 11 ou ``[PATCH net-next]`` para novas funcionalidades. 12- **Tag Fixes** – para correções, a tag ``Fixes:`` é obrigatória, 13 independentemente da árvore de destino. 14- **Tamanho da série** – não envie séries grandes (> 15 patches);divida-as em 15 partes menores. 16- **Intervalo de envio** – não reenvie seus patches dentro de um período de 24 17 horas. 18- **Reverse xmas tree** – organize as declarações de variáveis locais da mais 19 longa para a mais curta. 20 21netdev 22------ 23A **netdev** é a lista de discussão para todos os assuntos do Linux relacionados 24a rede. Isso inclui qualquer item encontrado em ``net/`` (ex: código principal 25como IPv6) e em ``drivers/net`` (ex: drivers específicos de hardware) na árvore 26de diretórios do Linux. 27 28Note que alguns subsistemas (ex: drivers de rede sem fio/wireless), que possuem 29um alto volume de tráfego, possuem suas próprias listas de discussão e árvores 30específicas. 31 32Como muitas outras listas de discussão do Linux, a lista netdev é hospedada no 33`kernel.org <https://www.kernel.org/>`_, com arquivos disponíveis em 34https://lore.kernel.org/netdev/. 35 36À exceção dos subsistemas mencionados anteriormente, todo o desenvolvimento de 37rede do Linux (ex: RFCs, revisões, comentários, etc.) ocorre na **netdev**. 38 39Ciclo de Desenvolvimento 40------------------------ 41 42Aqui está um pouco de informação contextual sobre a cadência de desenvolvimento 43do Linux. Cada nova versão (release) inicia-se com uma "janela de mesclagem" 44(*merge window*) de duas semanas, onde os mantenedores principais enviam suas 45novas implementações para o Linus para incorporação na árvore principal 46(*mainline tree*). 47 48Após as duas semanas, a janela de mesclagem é fechada e a versão é 49nomeada/etiquetada como ``-rc1``. Nenhuma funcionalidade nova é incorporada à 50árvore principal após isso -- espera-se apenas correções (*fixes*) para o 51conteúdo da rc1. 52 53Após cerca de uma semana coletando correções para a rc1, a rc2 é lançada. Isso 54se repete semanalmente até a rc7 (tipicamente; às vezes rc6 se o ritmo estiver 55calmo, ou rc8 se houver muita instabilidade); uma semana após a última vX.Y-rcN 56ser concluída, a versão oficial vX.Y é lançada. 57 58Para descobrir em que ponto do ciclo estamos agora - carregue a página da 59mainline (Linus) aqui: 60 61 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 62 63e observe o topo da seção de "tags". Se for rc1, estamos no início do ciclo 64de desenvolvimento. Se a rc7 foi marcada há uma semana, então um lançamento 65é provavelmente iminente. Se a tag mais recente for uma tag de lançamento 66final (sem o sufixo ``-rcN``) - muito provavelmente estamos em uma janela de 67mesclagem (*merge window*) e o ``net-next`` está fechado. 68 69Árvores git e fluxo de patches 70------------------------------ 71 72Existem duas árvores de rede (repositórios git) em jogo. Ambas são coordenadas 73por David Miller, o mantenedor principal de rede. Há a árvore ``net``e a árvore 74``net-next``. Como você provavelmente pode adivinhar pelos nomes, a árvore 75``net`` é para correções de código existente já na árvore mainline de Linus, e a 76``net-next`` é para onde o novo código vai para o lançamento futuro. 77Você pode encontrar as árvores aqui: 78 79- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git 80- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git 81 82Relacionando isso ao desenvolvimento do kernel: no início da janela de mesclagem 83(*merge window*) de 2 semanas, a árvore ``net-next`` será fechada, sem novas 84mudanças ou funcionalidades. O conteúdo novo acumulado nas últimas 10 semanas 85será passado para a mainline/Linus via um *pull request* para a vX.Y ao mesmo 86tempo, a árvore ``net`` começará a acumular correções para este conteúdo enviado 87relacionado à vX.Y. 88 89Um anúncio indicando quando a ``net-next`` foi fechada é geralmente enviado para 90a netdev, mas sabendo o que foi dito acima, você pode prever isso com 91antecedência. 92 93.. warning:: 94 95 Não envie novo conteúdo para a ``net-next`` para a netdev durante o período 96 em que a árvore ``net-next`` estiver fechada. 97 98Patches RFC enviados apenas para revisão são obviamente bem-vindos a qualquer 99momento (use ``--subject-prefix='RFC net-next'`` com ``git format-patch``). 100 101Pouco depois das duas semanas terem passado (e a vX.Y-rc1 ser lançada), a árvore 102para a ``net-next`` reabre para coletar conteúdo para o próximo lançamento 103(vX.Y+1). 104 105Se você não estiver inscrito na netdev e/ou simplesmente não tiver certeza se a 106``net-next`` já reabriu, basta verificar o link do repositório git da 107``net-next`` acima para quaisquer novos *commits* relacionados à rede. Você 108também pode verificar o seguinte site para o status atual: 109 110 https://netdev.bots.linux.dev/net-next.html 111 112A árvore ``net`` continua a coletar correções para o conteúdo da vX.Y e é 113enviada de volta para Linus em intervalos regulares (~semanais). Isso significa 114que o foco da ``net`` é a estabilização e correções de bugs. 115 116Finalmente, a vX.Y é lançada e todo o ciclo recomeça. 117 118Revisão de patches da netdev 119---------------------------- 120 121Status do patch 122~~~~~~~~~~~~~~~ 123 124O status de um patch pode ser verificado olhando a fila principal do patchwork 125para a netdev: 126 127 https://patchwork.kernel.org/project/netdevbpf/list/ 128 129O campo "State" informará exatamente onde as coisas estão com o seu patch: 130 131================= ============================================================ 132Estado do patch Descrição 133================= ============================================================ 134New, Under review revisão pendente, o patch está na fila do mantenedor 135 para revisão; os dois estados são usados alternadamente 136 (dependendo do co-mantenedor exato que estiver lidando 137 com o patchwork no momento) 138Accepted o patch foi aplicado à árvore de rede apropriada, 139 isso é geralmente definido de forma automática pelo pw-bot 140Needs ACK aguardando um "ack" de um especialista da área 141 ou testes 142Changes requested o patch não passou na revisão, espera-se uma nova 143 revisão com mudanças apropriadas no código e na mensagem 144 de commit 145Rejected o patch foi rejeitado e não se espera uma nova 146 revisão 147Not applicable espera-se que o patch seja aplicado fora do 148 subsistema de rede 149Awaiting upstream o patch deve ser revisado e tratado pelo sub-mantenedor 150 apropriado, que o enviará para as árvores de rede; 151 patches definidos como ``Awaiting upstream`` no patchwork 152 da netdev geralmente permanecerão neste estado, 153 independentemente de o sub-mantenedor ter solicitado 154 mudanças, aceito ou rejeitado o patch 155Deferred o patch precisa ser reenviado mais tarde, geralmente 156 devido a alguma dependência ou porque foi enviado para 157 uma árvore fechada 158Superseded uma nova versão do patch foi enviada, geralmente 159 definido pelo pw-bot 160RFC não deve ser aplicado, geralmente não está na 161 fila de revisão do mantenedor; o pw-bot pode definir 162 patches para este estado automaticamente com base nas 163 tags do assunto 164================= ============================================================ 165 166Os patches são indexados pelo cabeçalho ``Message-ID`` dos e-mails que os 167transportaram; portanto, se você tiver problemas para encontrar seu patch, 168anexe o valor do ``Message-ID`` à URL acima. 169 170Atualizando o status do patch 171----------------------------- 172 173Colaboradores e revisores não têm permissões para atualizar o estado do patch 174diretamente no patchwork. O Patchwork não expõe muitas informações sobre o 175histórico do estado dos patches; portanto, ter várias pessoas atualizando o 176estado leva a confusões. 177 178Em vez de delegar permissões do patchwork, a netdev usa um robô de e-mail 179simples (bot) que procura por comandos/linhas especiais dentro dos e-mails 180enviados para a lista de discussão. Por exemplo, para marcar uma série como 181Mudanças Solicitadas (*Changes Requested*), é necessário enviar a seguinte 182linha em qualquer lugar na thread do e-mail:: 183 184 pw-bot: changes-requested 185 186Como resultado, o bot definirá toda a série como Mudanças Solicitadas. Isso 187pode ser útil quando o autor descobre um bug em sua própria série e deseja 188evitar que ela seja aplicada. 189 190O uso do bot é totalmente opcional; em caso de dúvida, ignore completamente a 191existência dele. Os mantenedores classificarão e atualizarão o estado dos 192patches por conta própria. Nenhum e-mail deve ser enviado à lista com o 193propósito principal de se comunicar com o bot; os comandos do bot devem ser 194vistos como metadados. 195 196O uso do bot é restrito aos autores dos patches (o cabeçalho ``From:`` no envio 197do patch e no comando deve coincidir!), mantenedores do código modificado de 198acordo com o arquivo MAINTAINERS (novamente, o ``From:`` deve coincidir 199com a entrada no MAINTAINERS) e alguns revisores seniores. 200 201O bot registra sua atividade aqui: 202 203 https://netdev.bots.linux.dev/pw-bot.html 204 205Prazos de revisão 206~~~~~~~~~~~~~~~~~ 207 208De modo geral, os patches são triados rapidamente (em menos de 48h). Mas 209seja paciente; se o seu patch estiver ativo no patchwork (ou seja, listado 210na lista de patches do projeto), as chances de ele ter sido esquecido são 211próximas de zero. 212 213O alto volume de desenvolvimento na netdev faz com que os revisores encerrem 214discussões de forma relativamente rápida. É muito improvável que novos 215comentários e respostas cheguem após uma semana de silêncio. Se um 216patch não estiver mais ativo no patchwork e a thread ficar inativa por mais de 217uma semana - esclareça os próximos passos e/ou envie a próxima versão. 218 219Especificamente para envios de RFC, se ninguém responder em uma semana ou os 220revisores perderam o envio ou não têm opiniões fortes a respeito. Se o código 221estiver pronto, reenvie como um PATCH. 222 223E-mails dizendo apenas "ping" ou "bump" são considerados rudes. Se você não 224conseguir identificar o status do patch pelo patchwork ou onde a discussão 225parou - descreva sua melhor suposição e pergunte se ela está correta. Por 226exemplo:: 227 228 Não entendo quais são os próximos passos. A Pessoa X parece estar descontente 229 com A; devo fazer B e enviar novamente os patches? 230 231.. _Solicitações de mudanças: 232 233Mudanças solicitadas 234~~~~~~~~~~~~~~~~~~~~ 235 236Patches marcados como ``Changes Requested`` precisam ser revisados. A nova 237versão deve vir com um registro de alterações (changelog), 238preferencialmente incluindo links para as postagens anteriores, por exemplo:: 239 240 [PATCH net-next v3] net: faz as vacas dizerem "muuu" 241 242 Mesmo os usuários que não bebem leite apreciam ouvir as vacas dizendo 243 "muuu". 244 245 A quantidade de mugidos dependerá da taxa de pacotes, portanto, deve 246 corresponder muito bem ao ciclo diurno. 247 248 Signed-off-by: Joe Defarmer <joe@barn.org> 249 --- 250 v3: 251 - adicionada uma nota sobre a flutuação do mugido conforme a hora 252 do dia na 253 mensagem de commit 254 v2: https://lore.kernel.org/netdev/123themessageid@barn.org/ 255 - corrigido argumento ausente na kernel doc para netif_is_bovine() 256 - corrigido vazamento de memória (memory leak) em 257 netdev_register_cow() 258 v1: https://lore.kernel.org/netdev/456getstheclicks@barn.org/ 259 260A mensagem de commit deve ser revisada para responder a quaisquer perguntas que 261os revisores tenham feito em discussões anteriores. Ocasionalmente, a 262atualização da mensagem de commit será a única mudança na nova versão. 263 264Reenvios parciais 265~~~~~~~~~~~~~~~~~ 266 267Por favor, sempre reenvie a série completa de patches e certifique-se de 268numerar seus patches de forma que fique claro que este é o conjunto mais 269recente e completo de patches que pode ser aplicado. Não tente reenviar apenas 270os patches que foram alterados. 271 272Lidando com patches aplicados incorretamente 273~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 274 275Ocasionalmente, uma série de patches é aplicada antes de receber feedback 276crítico, ou a versão errada de uma série é aplicada. 277 278Não é possível fazer o patch desaparecer uma vez que ele foi enviado (pushed); 279o histórico de commits nas árvores netdev é imutável. Por favor, envie versões 280incrementais sobre o que foi mesclado para corrigir os patches da maneira que 281eles ficariam se a sua série de patches mais recente fosse mesclada. 282 283Em casos onde uma reversão completa (revert) é necessária, a reversão deve ser 284enviada como um patch para a lista com uma mensagem de commit explicando os 285problemas técnicos com o commit revertido. Reversões devem ser usadas como 286último recurso, quando a mudança original está completamente errada; correções 287incrementais são preferidas. 288 289Árvore estável 290~~~~~~~~~~~~~~ 291 292Embora antigamente as submissões para a netdev não devessem carregar tags 293explícitas ``CC: stable@vger.kernel.org``, esse não é mais o caso hoje em dia. 294Por favor, siga as regras padrão de estabilidade em 295``Documentation/process/stable-kernel-rules.rst``, e certifique-se de incluir as 296tags Fixes apropriadas! 297 298Correções de segurança 299~~~~~~~~~~~~~~~~~~~~~~ 300 301Não envie e-mails diretamente para os mantenedores da netdev se você acha que 302descobriu um bug que possa ter possíveis implicações de segurança. O atual 303mantenedor da netdev tem solicitado consistentemente que as pessoas usem as 304listas de discussão e não entrem em contato diretamente. Se você não estiver 305de acordo com isso, considere enviar um e-mail para security@kernel.org ou 306ler sobre http://oss-security.openwall.org/wiki/mailing-lists/distros como 307possíveis mecanismos alternativos. 308 309Envio conjunto de mudanças em componentes de espaço do usuário 310~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 311 312O código de espaço do usuário (*user space*) que exercita funcionalidades do 313kernel deve ser enviado juntamente com os patches do kernel. Isso dá aos 314revisores a chance de ver como qualquer nova interface é usada e quão 315bem ela funciona. 316 317Quando as ferramentas de espaço do usuário residem no próprio repositório do 318kernel, todas as alterações devem geralmente vir em uma única série. Se a série 319se tornar muito grande ou se o projeto de espaço do usuário não for revisado na 320netdev, inclua um link para um repositório público onde os patches de espaço do 321usuário possam ser vistos. 322 323No caso de ferramentas de espaço do usuário residirem em um repositório 324separado, mas serem revisadas na netdev (por exemplo, patches para ferramentas 325``iproute2``), os patches do kernel e do espaço do usuário devem formar séries 326(threads) separadas quando postados na lista de discussão, por exemplo:: 327 328 [PATCH net-next 0/3] net: carta de apresentação de alguma funcionalidade 329 └─ [PATCH net-next 1/3] net: preparação para alguma funcionalidade 330 └─ [PATCH net-next 2/3] net: implementação de alguma funcionalidade 331 └─ [PATCH net-next 3/3] selftest: net: alguma funcionalidade 332 333 [PATCH iproute2-next] ip: adiciona suporte para alguma funcionalidade 334 335A postagem em uma única thread é desencorajada porque confunde o patchwork 336(a partir da versão 2.2.2 do patchwork). 337 338Envio conjunto de selftests 339~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 340 341Os selftests devem fazer parte da mesma série que as mudanças de código. 342Especificamente para correções, tanto a mudança de código quanto o teste 343relacionado devem ir para a mesma árvore (os testes podem não ter uma tag 344Fixes, o que é esperado). Misturar mudanças de código e mudanças de teste em 345um único commit é desencorajado. 346 347Preparando as mudanças 348---------------------- 349 350Atenção aos detalhes é importante. Releia seu próprio trabalho como se você 351fosse o revisor. Você pode começar usando o ``checkpatch.pl``, talvez até com 352a flag ``--strict``. Mas não seja robótico e irracional ao fazer isso. Se sua 353mudança for uma correção de bug, certifique-se de que seu log de commit indique 354o sintoma visível para o usuário final, a razão subjacente de por que isso 355acontece e, se necessário, explique por que a correção proposta é a melhor 356maneira de resolver as coisas. Não corrompa espaços em branco e, como é comum, 357não use recuos incorretos em argumentos de função que abrangem várias linhas. 358Se for o seu primeiro patch, envie-o para si mesmo por e-mail para que você 359possa testar a aplicação em uma árvore sem patches para confirmar que a 360infraestrutura não o danificou. 361 362Finalmente, volte e leia ``Documentation/process/submitting-patches.rst`` 363para ter certeza de que não está repetindo algum erro comum documentado lá. 364 365Indicando a árvore de destino 366~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 367 368Para ajudar os mantenedores e os bots de CI, você deve marcar explicitamente 369qual árvore seu patch tem como alvo. Supondo que você use git, utilize a flag 370de prefixo:: 371 372 git format-patch --subject-prefix='PATCH net-next' inicio..fim 373 374Use ``net`` em vez de ``net-next`` (sempre em letras minúsculas) no comando 375acima para conteúdos de correção de bugs da árvore ``net``. 376 377Dividindo o trabalho em patches 378~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 379 380Coloque-se no lugar do revisor. Cada patch é lido separadamente e, portanto, 381deve constituir um passo compreensível em direção ao seu objetivo declarado. 382 383Evite enviar séries com mais de 15 patches. Séries maiores levam mais tempo 384para serem revisadas, pois os revisores adiarão a análise até encontrarem um 385grande bloco de tempo disponível. Uma série pequena pode ser revisada em pouco 386tempo, então os mantenedores simplesmente a revisam de imediato. Como resultado, 387uma sequência de séries menores é mesclada mais rapidamente e com melhor 388cobertura de revisão. Reenviar séries grandes também aumenta o tráfego na lista 389de discussão. 390 391Limitar patches pendentes na lista de discussão 392----------------------------------------------- 393 394Evite ter mais de 15 patches, em todas as séries, pendentes de revisão na lista 395de discussão para uma única árvore. Em outras palavras, um máximo de 15 patches 396sob revisão na ``net`` e um máximo de 15 patches sob revisão na ``net-next``. 397 398Este limite tem o objetivo de focar o esforço do desenvolvedor nos testes dos 399patches antes da revisão upstream, auxiliando a qualidade das submissões 400upstream e aliviando a carga sobre os revisores. 401 402Ordenação de variáveis locais ("árvore invertida", "RCS") 403~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 404 405A netdev tem uma convenção para ordenar variáveis locais em funções. Ordene as 406linhas de declaração de variáveis da mais longa para a mais curta, por exemplo:: 407 408 struct scatterlist *sg; 409 struct sk_buff *skb; 410 int err, i; 411 412Se houver dependências entre as variáveis que impeçam a ordenação, mova a 413inicialização para fora da linha de declaração. 414 415Precedência de formatação 416~~~~~~~~~~~~~~~~~~~~~~~~~ 417 418Ao trabalhar em código existente que utiliza formatação não padrão, faça com 419que seu código siga as diretrizes mais recentes, para que, eventualmente, 420todo o código no domínio da netdev esteja no formato preferido. 421 422Uso de construções gerenciadas por dispositivo e cleanup.h 423~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 424 425Historicamente, a netdev permanece cética em relação às promessas de todas as 426APIs de "auto-limpeza" (auto-cleanup), incluindo até mesmo os auxiliares 427``devm_``. Eles não são o estilo preferido de implementação, apenas um estilo 428aceitável. 429 430O uso de ``guard()`` é desencorajado em qualquer função com mais de 20 linhas; 431``scoped_guard()`` é considerado mais legível. O uso de lock/unlock normal 432ainda é (levemente) preferido. 433 434Construções de limpeza de baixo nível (como ``__free()``) podem ser usadas ao 435construir APIs e auxiliares, especialmente iteradores com escopo. No entanto, o 436uso direto de ``__free()`` dentro do núcleo de rede (networking core) e drivers 437é desencorajado. Orientações semelhantes se aplicam à declaração de variáveis 438no meio da função. 439 440Patches de limpeza (Clean-up patches) 441~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 442 443A netdev desencoraja patches que realizam limpezas simples que não estejam no 444contexto de outro trabalho. Por exemplo: 445 446* Tratar avisos do ``checkpatch.pl`` e outros avisos triviais de estilo de 447 codificação 448* Tratar problemas de Ordenação de variáveis locais 449* Conversões para APIs gerenciadas por dispositivo (auxiliares ``devm_``) 450 451Isso ocorre porque se considera que a agitação (*churn*) que tais mudanças 452produzem tem um custo maior do que o valor de tais limpezas. 453 454Por outro lado, correções de ortografia e gramática não são desencorajadas. 455 456Reenviando após a revisão 457~~~~~~~~~~~~~~~~~~~~~~~~~ 458 459Aguarde pelo menos 24 horas entre as postagens. Isso garantirá que revisores de 460todas as localizações geográficas tenham a chance de se manifestar. Não espere 461muito tempo (semanas) entre as postagens, pois isso tornará mais difícil para 462os revisores lembrarem de todo o contexto. 463 464Certifique-se de tratar todo o feedback em sua nova postagem. Não envie uma 465nova versão do código se a discussão sobre a versão anterior ainda estiver em 466andamento, a menos que seja instruído diretamente por um revisor. 467 468A nova versão dos patches deve ser postada como uma thread separada, não como 469uma resposta à postagem anterior. O registro de alterações (changelog) deve 470incluir um link para a postagem anterior (veja :ref:`Solicitações 471de mudanças`). 472 473Testes 474------ 475 476Nível de teste esperado 477~~~~~~~~~~~~~~~~~~~~~~~ 478 479No mínimo, suas alterações devem passar por uma compilação ``allyesconfig`` e 480uma ``allmodconfig`` com ``W=1`` definido, sem novos avisos ou falhas. 481 482O ideal é que você tenha feito testes em tempo de execução específicos para sua 483alteração, e que a série de patches contenha um conjunto de selftests do kernel 484para ``tools/testing/selftests/net`` ou usando o framework KUnit. 485 486Espera-se que você teste suas alterações no topo da árvore de rede relevante 487(``net`` ou ``net-next``) e não, por exemplo, em uma árvore estável ou na 488``linux-next``. 489 490Verificações do patchwork 491~~~~~~~~~~~~~~~~~~~~~~~~~ 492 493As verificações (*checks*) no patchwork são, em sua maioria, wrappers simples 494em torno de scripts existentes do kernel; as fontes estão disponíveis em: 495 496https://github.com/linux-netdev/nipa/tree/master/tests 497 498**Não** envie seus patches apenas para executá-los nas verificações. Você deve 499garantir que seus patches estejam prontos, testando-os localmente antes de 500postar na lista de discussão. A instância do bot de build do patchwork fica 501sobrecarregada com muita facilidade e a netdev@vger realmente não precisa de 502mais tráfego se pudermos evitar. 503 504netdevsim 505~~~~~~~~~ 506 507O ``netdevsim`` é um driver de teste que pode ser usado para exercitar APIs de 508configuração de driver sem a necessidade de hardware compatível. Mock-ups e 509testes baseados no ``netdevsim`` são fortemente encorajados ao adicionar novas 510APIs, mas o ``netdevsim`` em si **não** é considerado um caso de uso/usuário. 511Você também deve implementar as novas APIs em um driver real. 512 513Não damos garantias de que o ``netdevsim`` mudará no futuro de uma forma que 514quebraria o que normalmente seria considerado uAPI. O ``netdevsim`` é reservado 515apenas para uso por testes upstream, portanto, quaisquer novos recursos do 516``netdevsim`` devem ser acompanhados de selftests em ``tools/testing/selftests/``. 517 518Status de suporte para drivers 519------------------------------ 520 521.. note: 522 523Os requisitos a seguir aplicam-se apenas a drivers de NIC Ethernet. 524 525A netdev define requisitos adicionais para drivers que desejam adquirir o status 526``Supported`` (Suportado) no arquivo MAINTAINERS. Drivers ``Supported`` devem 527executar todos os testes de driver upstream e relatar os resultados duas vezes 528por dia. Drivers que não cumprirem este requisito devem usar o status 529``Maintained`` (Mantido). Atualmente, não há diferença na forma como os drivers 530``Supported`` e ``Maintained`` são tratados no upstream. 531 532As regras exatas que um driver deve seguir para adquirir o status ``Supported``: 533 5341. Deve executar todos os testes sob os alvos ``drivers/net`` e 535 ``drivers/net/hw`` dos selftests do Linux. A execução e o relato 536 de testes privados / internos também são bem-vindos, mas os testes 537 upstream são obrigatórios. 538 5392. A frequência mínima de execução é uma vez a cada 12 horas. Deve 540 testar o branch designado a partir do feed de branches selecionado. 541 Observe que os branches são construídos automaticamente e estão 542 expostos à postagem intencional de patches maliciosos; portanto, 543 os sistemas de teste devem ser isolados. 544 5453. Drivers que suportam múltiplas gerações de dispositivos devem 546 testar pelo menos um dispositivo de cada geração. Um manifesto do 547 ambiente de teste (*testbed manifest* - formato exato a definir) 548 deve descrever os modelos de dispositivos testados. 549 5504. Os testes devem ser executados de forma confiável; se múltiplos 551 branches forem ignorados ou se os testes falharem devido a problemas 552 no ambiente de execução, o status ``Supported`` será retirado. 553 5545. Falhas nos testes devido a bugs no driver ou no próprio teste, 555 ou falta de suporte para a funcionalidade que o teste visa, *não* 556 são motivo para a perda do status ``Supported``. 557 558O CI da netdev manterá uma página oficial de dispositivos suportados, listando 559seus resultados de testes recentes. 560 561O mantenedor do driver pode providenciar para que outra pessoa execute o teste; 562não há exigência de que a pessoa listada como mantenedora (ou seu empregador) 563seja responsável pela execução dos testes. Colaborações entre 564fornecedores, hospedagem de CI no GitHub (GH CI), outros repositórios sob o 565linux-netdev, etc., são muito bem-vindas. 566 567Veja https://github.com/linux-netdev/nipa/wiki para mais informações sobre o CI 568da netdev. Sinta-se à vontade para entrar em contato com os mantenedores ou com 569a lista para quaisquer dúvidas. 570 571Orientações para revisores 572-------------------------- 573 574Revisar patches de outras pessoas na lista é altamente incentivado, 575independentemente do nível de experiência. Para orientações gerais e dicas 576úteis, consulte `revisão de tópicos avançados de desenvolvimento`. 577 578É seguro assumir que os mantenedores da netdev conhecem a comunidade e o nível 579de experiência dos revisores. Os revisores não devem se preocupar com o fato de 580seus comentários impedirem ou desviarem o fluxo de patches. Revisores menos 581experientes são fortemente incentivados a fazer uma revisão mais aprofundada das 582submissões e não focar exclusivamente em questões triviais ou subjetivas, como 583formatação de código, tags, etc. 584 585Depoimentos / feedback 586---------------------- 587 588Algumas empresas utilizam o feedback de colegas em revisões de desempenho de 589funcionários. Sinta-se à vontade para solicitar feedback dos mantenedores da 590netdev, especialmente se você dedica uma quantidade significativa de tempo 591revisando código e se esforça além do esperado para melhorar a infraestrutura 592compartilhada. 593 594O feedback deve ser solicitado por você, o colaborador, e será sempre 595compartilhado com você (mesmo que você solicite que ele seja enviado ao seu 596gerente).