Resguardo inicial

linux-7.2.3/Documentation/translations/pt_BR/process/1.Intro.rst

@@ -0,0 +1,269 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Introdução
+==========
+
+Sumário
+-------
+
+O restante desta seção cobre o processo de desenvolvimento do kernel e os
+tipos de frustração que os desenvolvedores e empresas podem encontrar pelo
+caminho. Existem diversas razões que justificam a recomendação para que seja
+feito o merge do código do kernel ao kernel principal ("mainline"), como
+disponibilidade automática aos usuários, suporte da comunidade em diversas
+formas, e a oportunidade de influenciar a direção do desenvolvimento do
+kernel. Contribuições ao kernel Linux obrigatoriamente devem estar disponíveis
+sob uma licença compatível com a GPL.
+
+:ref:`development_process` apresenta o processo de desenvolvimento, o ciclo de
+lançamento, e a mecânica da janela de merge. As várias fases no desenvolvimento
+de patch, revisão, e ciclo de merge são explicadas. Algumas ferramentas e
+listas de e-mail são discutidas. Desenvolvedores que queiram começar a
+desenvolver o kernel são encorajados a buscar e corrigir bugs como exercício
+inicial.
+
+:ref:`development_early_stage` cobre os primeiros passos do processo de
+desenvolvimento, com ênfase no envolvimento da comunidade de desenvolvedores o
+mais cedo possível.
+
+:ref:`development_coding` é sobre o processo de codificação; muitas armadilhas
+já encontradas por outros desenvolvedores são discutidas. Alguns requisitos
+para patches são explicados, e é feita uma introdução para algumas ferramentas
+que podem ajudar a garantir que os patches de kernel estão corretos.
+
+:ref:`development_posting` fala sobre o processo de envio de patches para
+revisão. Para serem levados em consideração pela comunidade desenvolvedora, os
+patches devem estar devidamente formatados e descritos, assim como devem estar
+no lugar correto. Seguir os conselhos dessa seção pode ajudar na recepção
+positiva do seu trabalho.
+
+:ref:`development_followthrough` cobre o que acontece após o envio dos patches;
+o trabalho ainda está longe de estar concluído. Trabalhar com os revisores é
+parte crucial do processo de desenvolvimento; essa seção oferece dicas de como
+evitar problemas nesse estágio importante. Desenvolvedores são alertados a não
+presumir que o trabalho acabou após o merge do patch no "mainline".
+
+:ref:`development_advancedtopics` introduz dois tópicos mais "avançados":
+gerenciamento de patches com git e revisão de patches por outros.
+
+:ref:`development_conclusion` conclui o documento com indicações de fontes com
+mais informações sobre o desenvolvimento do kernel.
+
+Sobre este documento
+--------------------
+
+O kernel Linux, com mais de 8 milhões de linhas de código e bem mais de 1000
+contribuintes a cada lançamento ("release"), é um dos maiores e mais ativos
+projetos de software livre em existência. Desde seu modesto início em 1991,
+este kernel evoluiu para se tornar um dos melhores componentes de sistemas
+operacionais, rodando em pequenos players de música digital, PCs de mesa, os
+maiores supercomputadores em existência, e todos os outros tipos de sistema
+entre eles. É robusto, eficiente, e uma solução escalável para quase toda
+situação.
+
+O crescimento do Linux trouxe o aumento no número de desenvolvedores (e
+empresas) desejando participar no seu desenvolvimento. Fabricantes de hardware
+querem garantir que o Linux suporte bem os seus produtos, tornando-os atrativos
+para usuários Linux. Fabricantes de sistemas embarcados, que usam o Linux como
+componente em um produto integrado, querem que o Linux seja tão capaz e
+adequado quanto possível para a tarefa em questão. Distribuidores de software
+que baseiam seus produtos em Linux têm claro interesse nas capacidades,
+performance, e confiabilidade do kernel Linux. É também comum que usuários
+finais queiram alterar o Linux para atender melhor suas necessidades.
+
+Uma das características mais atrativas do Linux é sua facilidade de acesso a
+esses desenvolvedores; qualquer um com as habilidades necessárias pode melhorar
+o Linux e influenciar a direção do seu desenvolvimento. Produtos proprietários
+não conseguem oferecer esse tipo de abertura, que é característico do processo
+de software livre. O kernel é ainda mais acessível que a maioria dos outros
+projetos de software livre. Um ciclo típico de três meses de desenvolvimento
+do kernel pode envolver mais de 1000 desenvolvedores trabalhando para mais de
+100 empresas (ou absolutamente nenhuma empresa).
+
+Trabalhar com a comunidade de desenvolvimento do kernel não é uma tarefa árdua.
+Contudo, muitos colaboradores potenciais passaram por dificuldades ao tentar
+trabalhar no kernel. A comunidade evoluiu suas próprias formas de funcionamento
+que permitem operar de forma fluida (e produzir um produto de alta qualidade)
+em um ambiente em que milhares de linhas de código são alteradas todos os dias.
+Não é surpresa que o processo de desenvolvimento do kernel Linux seja muito
+diferente dos modelos de desenvolvimento proprietários.
+
+O processo de desenvolvimento do kernel pode parecer estranho e intimidador
+para novos desenvolvedores, mas existem bons motivos e uma sólida experiência
+por trás disso. Um desenvolvedor que não entenda os caminhos próprios da
+comunidade kernel (ou pior, que tente menosprezá-los ou contorná-los) terá uma
+experiência frustrante pela frente. A comunidade de desenvolvimento ajuda
+aqueles que tentam aprender, mas gasta pouco tempo com aqueles que não escutam
+ou não ligam para o processo de desenvolvimento.
+
+Espera-se que aqueles que leiam este documento sejam capazes de evitar essa
+experiência frustrante. Há muito material aqui, mas o esforço envolvido na sua
+leitura valerá a pena. A comunidade de desenvolvimento sempre necessita de
+desenvolvedores que ajudem a melhorar o kernel; o texto a seguir deve ajudar
+você - ou aqueles trabalhando para você - a se juntar à nossa comunidade.
+
+Créditos
+--------
+
+Esse documento foi escrito por Jonathan Corbet, corbet@lwn.net. Aprimorado
+pelos comentários de Johannes Berg, James Berry, Alex Chiang, Roland Dreier,
+Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda
+McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, e Jochen Voß.
+
+Esse trabalho contou com o apoio da Linux Foundation; agradecimentos especiais
+para Amanda McPherson, que viu o valor desse esforço e fez tudo acontecer.
+
+A importância de levar o código até o "mainline"
+-------------------------------------------------
+
+Algumas empresas e desenvolvedores ocasionalmente se perguntam por que devem
+se importar em aprender como trabalhar com a comunidade do kernel e ter seu
+código no "mainline" (o kernel mantido por Linus Torvalds e usado como base
+para os distribuidores Linux). No curto prazo, contribuir com o código pode
+parecer um gasto evitável; parece mais fácil apenas manter o seu código à
+parte e oferecer suporte direto aos usuários. A verdade é que manter código
+fora da árvore principal ("out-of-tree") é uma falsa economia.
+
+Para ilustrar os custos do código "out-of-tree", aqui estão alguns aspectos
+relevantes do processo de desenvolvimento do kernel; a maioria será discutida
+com mais detalhes adiante neste documento. Considere:
+
+- Código integrado via merge ao "mainline" fica disponível para todos os
+  usuários Linux. Estará automaticamente presente em todas as distribuições
+  que o habilitarem. Não há necessidade de discos de armazenamento, downloads,
+  ou as complicações de dar suporte a múltiplas versões de variadas
+  distribuições; tudo simplesmente funciona, para o desenvolvedor e para o
+  usuário. Incorporação ao "mainline" resolve um grande número de problemas
+  de distribuição e suporte.
+
+- Enquanto desenvolvedores do kernel se esforçam para manter uma interface
+  estável para o espaço do usuário, a API interna está em constante mudança.
+  A ausência de uma interface interna estável é uma escolha deliberada de
+  design; permite que sejam feitas melhorias fundamentais a qualquer tempo e
+  resulta em código de qualidade superior. Uma consequência dessa política é
+  que código "out-of-tree" precisa ser constantemente atualizado para que
+  continue funcionando com novos kernels. Manter código "out-of-tree" requer
+  significativo trabalho apenas para mantê-lo funcionando.
+
+  Por sua vez, código que está no "mainline" não precisa dessa manutenção,
+  resultado de uma regra simples que exige que qualquer desenvolvedor que
+  altere uma API, também conserte qualquer código que deixe de funcionar como
+  resultado da alteração. Código que teve o merge realizado no "mainline" tem
+  custo significativamente menor de manutenção.
+
+- Além disso, código que está no kernel será muitas vezes melhorado por outros
+  desenvolvedores. Resultados surpreendentes podem surgir ao permitir que sua
+  comunidade de usuários e clientes melhore seu produto.
+
+- Código do kernel está sujeito a revisão, tanto antes como depois do merge ao
+  "mainline". Independentemente das habilidades do desenvolvedor original, o
+  processo de revisão invariavelmente encontra maneiras de evoluí-lo. Bugs
+  severos e problemas de segurança são constantemente encontrados durante o
+  processo de revisão. Isso é especialmente válido para código desenvolvido em
+  ambiente isolado; tais códigos se beneficiam fortemente ao serem revistos por
+  outros desenvolvedores. Código "out-of-tree" é código de baixa qualidade.
+
+- Participação no processo de desenvolvimento é a forma pela qual você pode
+  influenciar a direção do desenvolvimento do kernel. Usuários que se queixam
+  externamente são ouvidos, porém desenvolvedores ativos têm maior poder de
+  articulação - e a habilidade de implementar mudanças que façam o kernel
+  funcionar melhor para suas necessidades.
+
+- Quando o código é mantido à parte, sempre existe a possibilidade de que
+  terceiros contribuam para uma implementação diferente de uma funcionalidade
+  parecida. Se isso acontecer, ter seu código integrado via merge se tornará
+  muito mais difícil - ao ponto de ser impossível. Você enfrentará duas
+  alternativas desagradáveis, (1) manter uma funcionalidade "out-of-tree"
+  indefinidamente ou (2) abandonar seu código e migrar seus usuários para a
+  versão na árvore principal ("in-tree").
+
+- Contribuição de código é a ação fundamental que faz todo o processo
+  funcionar. Ao contribuir com seu código você pode adicionar nova
+  funcionalidade ao kernel e proporcionar capacidades e exemplos que podem ser
+  usados por outros desenvolvedores de kernel. Se você desenvolveu código para
+  o Linux (ou está pensando em desenvolver), você claramente tem interesse na
+  continuidade do sucesso dessa plataforma; contribuição de código é uma das
+  melhores maneiras de garantir esse sucesso.
+
+Todos os argumentos acima se aplicam a qualquer código "out-of-tree", incluindo
+código distribuído de maneira proprietária, em formato exclusivamente binário.
+Existem fatores adicionais que devem ser levados em consideração antes de
+qualquer distribuição de código de kernel apenas em binário, incluindo:
+
+- As questões legais da distribuição de kernel proprietário são, no melhor dos
+  casos, confusas; muitos detentores de direitos autorais do kernel acreditam
+  que a maioria dos módulos binários são produtos derivados do kernel e que,
+  como resultado, sua distribuição é uma violação da Licença Pública Geral GNU
+  ("GNU General Public License"), que será tratada com mais profundidade abaixo.
+  Este autor não é um advogado, e nada neste documento pode ser considerado
+  aconselhamento jurídico. O verdadeiro status de módulos privados ("closed
+  source") só pode ser determinado judicialmente. Independentemente disso, a
+  incerteza que cerca esses módulos existe.
+
+- Os módulos binários aumentam consideravelmente a dificuldade de depuração de
+  problemas do kernel ("debugging"), a ponto de a maioria dos desenvolvedores
+  de kernel sequer tentar. Portanto, a distribuição de módulos exclusivamente
+  binários tornará mais difícil que os seus usuários recebam suporte.
+
+- O suporte também é mais difícil para distribuidores de módulos exclusivamente
+  binários, que precisam fornecer uma versão do módulo para cada distribuição e
+  cada versão do kernel que desejam suportar. Dezenas de versões de um único
+  módulo podem ser necessárias para fornecer uma cobertura razoavelmente
+  abrangente, e seus usuários terão que atualizar seu módulo separadamente
+  sempre que atualizarem seu kernel.
+
+- Tudo o que foi dito acima sobre revisão de código se aplica em dobro ao
+  código fechado. Como esse código não está disponível, ele não pode ter sido
+  revisado pela comunidade e, sem dúvida, terá sérios problemas.
+
+Os fabricantes de sistemas embarcados, em particular, podem ser tentados a
+ignorar grande parte do que foi dito nesta seção, acreditando que estão
+lançando um produto autossuficiente que usa uma versão congelada do kernel e
+não requer mais desenvolvimento após o lançamento. Esse argumento ignora o
+valor de uma revisão de código abrangente e o valor de permitir que seus
+usuários adicionem recursos ao seu produto. Mas esses produtos também têm uma
+vida comercial limitada, após a qual uma nova versão deve ser lançada. Nesse
+ponto, os fornecedores cujo código está no "mainline" e bem mantido estarão em
+uma posição muito melhor para preparar o novo produto para o mercado
+rapidamente.
+
+Licenciamento
+-------------
+
+Código é submetido ao kernel do Linux sob diversas licenças, mas todo ele deve
+ser compatível com a versão 2 da Licença Pública Geral GNU (GPLv2), que é a
+licença que cobre a distribuição do kernel como um todo. Na prática, isso
+significa que todas as contribuições de código são cobertas pela GPLv2 (com,
+opcionalmente, uma linguagem que permita a distribuição sob versões posteriores
+da GPL) ou pela licença BSD de três cláusulas. Quaisquer contribuições que não
+sejam cobertas por uma licença compatível não serão aceitas no kernel.
+
+A cessão de direitos autorais não é exigida (nem solicitada) para o código
+contribuído para o kernel. Todo o código incorporado ao kernel principal mantém
+sua titularidade original; como resultado, o kernel agora tem milhares de
+proprietários.
+
+Uma implicação dessa estrutura de propriedade é que qualquer tentativa de
+alterar o licenciamento do kernel está fadada ao fracasso quase certo. Existem
+poucos cenários práticos em que o acordo de todos os detentores de direitos
+autorais poderia ser obtido (ou seu código removido do kernel). Portanto, em
+particular, não há perspectiva de migração para a versão 3 da GPL em um futuro
+próximo.
+
+É imprescindível que todo o código contribuído para o kernel seja legitimamente
+software livre. Por esse motivo, código de contribuidores sem identidade
+conhecida ou contribuidores anônimos não será aceito. Todos os contribuidores
+são obrigados a "assinar" seu código, declarando que ele pode ser distribuído
+com o kernel sob a GPL. Código que não tenha sido licenciado como software
+livre por seu proprietário, ou que apresente risco de criar problemas
+relacionados a direitos autorais para o kernel (como código derivado de
+esforços de engenharia reversa sem as devidas salvaguardas) não pode ser
+contribuído.
+
+Questões sobre direitos autorais são comuns em listas de discussão de
+desenvolvimento Linux. Normalmente, essas perguntas recebem muitas respostas,
+mas é importante lembrar que as pessoas que respondem a essas perguntas não são
+advogados e não podem fornecer aconselhamento jurídico. Se você tiver dúvidas
+jurídicas relacionadas ao código-fonte do Linux, não há substituto para
+conversar com um advogado especializado nessa área. Confiar em respostas
+obtidas em listas de discussão técnicas é arriscado.

linux-7.2.3/Documentation/translations/pt_BR/process/2.Process.rst

@@ -0,0 +1,520 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Como funciona o processo de desenvolvimento
+===========================================
+
+O desenvolvimento do kernel Linux no início dos anos 1990 era uma
+atividade bastante informal, envolvendo um número relativamente pequeno de
+usuários e desenvolvedores. Com uma base de usuários atualmente na casa
+dos milhões e com cerca de 2.000 desenvolvedores envolvidos ao longo de
+um ano, o kernel desde então teve que evoluir uma série de processos
+para manter o desenvolvimento acontecendo de forma fluida. Uma
+compreensão sólida de como o processo funciona é necessária para ser uma
+parte eficaz dele.
+
+A Visão Geral
+-------------
+
+O kernel Linux usa um modelo de desenvolvimento de lançamento contínuo
+(*rolling release*), vagamente baseado em tempo. Um novo lançamento de
+versão principal do kernel (que chamaremos, como exemplo, de 9.x) [1]_
+ocorre a cada dois ou três meses, trazendo novos recursos, alterações em
+APIs internas e muito mais. Um lançamento típico pode conter cerca de
+13.000 conjuntos de alterações (*changesets*) com modificações em várias
+centenas de milhares de linhas de código. Lançamentos recentes,
+juntamente com suas datas, podem ser encontrados na `Wikipedia
+<https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_.
+
+.. [1] Rigorosamente falando, o kernel Linux não utiliza o esquema de
+       numeração de versionamento semântico, mas, em vez disso, o par
+       9.x identifica a versão de lançamento principal como um número
+       inteiro. Para cada lançamento, x é incrementado, mas o 9 é
+       incrementado apenas se x for considerado grande o suficiente
+       (por exemplo, o Linux 5.0 foi lançado após o Linux 4.20).
+
+O processo de integração (*merging*) de patches segue um fluxo simples a
+cada lançamento. No início de cada ciclo de desenvolvimento, abre-se a
+**"janela de integração" (*merge window*)**. Durante esse período, todo
+código considerado estável e aprovado pela comunidade é unificado ao
+kernel principal (*mainline*). A maior parte das novidades  e todas as
+grandes mudanças estruturais — entra obrigatoriamente nessa fase, em um
+ritmo frenético que chega a **1.000 patches (ou conjuntos de alterações)
+por dia**.
+
+(Como observação secundária, vale destacar que as mudanças integradas durante
+a janela de integração não surgem do nada; elas foram coletadas, testadas e
+organizadas com antecedência. Como esse processo funciona será descrito em
+detalhes mais adiante).
+
+A janela de integração dura aproximadamente duas semanas. Ao final desse
+período, Linus Torvalds declarará que a janela está fechada e lançará o
+primeiro dos kernels "rc". Para o kernel que está destinado a ser o 9.x,
+por exemplo, o lançamento que ocorre ao final da janela de integração será
+chamado de 9.x-rc1. O lançamento -rc1 é o sinal de que o prazo para integrar
+novos recursos terminou e que o período para estabilizar o próximo kernel
+começou.
+
+Ao longo das próximas seis a dez semanas, apenas patches que corrijam
+problemas devem ser submetidos ao kernel principal. Ocasionalmente, uma
+mudança mais significativa será permitida, mas esses casos são raros;
+desenvolvedores que tentam integrar novos recursos fora da janela de
+integração costumam receber uma recepção pouco amigável. Como regra geral,
+se você perder a janela de integração para um determinado recurso, o melhor
+a fazer é esperar pelo próximo ciclo de desenvolvimento. (Abre-se uma
+exceção ocasional para drivers de hardware que antes não eram suportados;
+se eles não modificarem nenhum código já existente na árvore, não podem
+causar regressões e deve ser seguro adicioná-los a qualquer momento).
+
+À medida que as correções são integradas ao kernel principal, o ritmo de
+envio de patches diminui com o tempo. Linus lança novos kernels -rc cerca
+de uma vez por semana; uma série normal chega a algo entre -rc6 e -rc9 antes
+que o kernel seja considerado suficientemente estável e o lançamento final
+seja realizado. Nesse ponto, todo o processo recomeça.
+
+Como exemplo, veja como ocorreu o ciclo de desenvolvimento da versão 5.4
+(todas as datas são de 2019):
+
+	==============  ===============================
+	Setembro 15	5.3 Lançamento estável do 5.3
+	Setembro 30	5.4-rc1, fechamento da janela de integração
+	Outubro 6	5.4-rc2
+	Outubro 13	5.4-rc3
+	Outubro 20	5.4-rc4
+	October 27	5.4-rc5
+	Novembro 3	5.4-rc6
+	Novembro 10	5.4-rc7
+	Novembro 17	5.4-rc8
+	Novembro 24	5.4 Lançamento estável do 5.4
+	==============  ===============================
+
+Como os desenvolvedores decidem quando encerrar o ciclo de desenvolvimento
+e criar o lançamento estável? A métrica mais significativa utilizada é a
+lista de regressões de lançamentos anteriores. Nenhum bug é bem-vindo, mas
+aqueles que quebram sistemas que funcionavam no passado são considerados
+especialmente graves. Por esta razão, patches que causam regressões são
+vistos de forma desfavorável e têm grande probabilidade de serem revertidos
+durante o período de estabilização.
+
+O objetivo dos desenvolvedores é corrigir todas as regressões conhecidas
+antes que o lançamento estável seja feito. No mundo real, esse tipo de
+perfeição é difícil de alcançar; há simplesmente variáveis demais em um
+projeto deste tamanho. Chega um ponto em que adiar o lançamento final apenas
+torna o problema pior; o volume de mudanças esperando pela próxima janela de
+integração crescerá ainda mais, criando ainda mais regressões no ciclo
+seguinte. Portanto, a maioria dos kernels é lançada com um pequeno número de
+regressões conhecidas, embora, felizmente, nenhuma delas seja grave.
+
+Assim que um lançamento estável é feito, sua manutenção contínua é passada
+para a "equipe estável" (*stable team*), atualmente composta por Greg
+Kroah-Hartman e Sasha Levin. A equipe estável lançará atualizações ocasionais
+para a versão estável utilizando o esquema de numeração 9.x.y.
+
+Para ser considerado para um lançamento de atualização, um patch deve (1)
+corrigir um bug significativo e (2) já estar integrado ao kernel principal
+(*mainline*) para o próximo kernel de desenvolvimento. Os kernels normalmente
+receberão atualizações estáveis por um pouco mais de um ciclo de
+desenvolvimento após o seu lançamento inicial. Assim, por exemplo, o histórico
+do kernel 5.2 ocorreu da seguinte forma (todas as datas são de 2019):
+
+  ==============  ===============================
+  7 de Julho      Lançamento estável do 5.2
+  14 de Julho     5.2.1
+  21 de Julho     5.2.2
+  26 de Julho     5.2.3
+  28 de Julho     5.2.4
+  31 de Julho     5.2.5
+  ...             ...
+  11 de Outubro   5.2.21
+  ==============  ===============================
+
+A versão 5.2.21 foi a última atualização estável do lançamento 5.2.
+
+Alguns kernels são designados como kernels de "longo prazo" (*long term*);
+eles receberão suporte por um período mais longo. Por favor, consulte o
+seguinte link para obter a lista de versões ativas do kernel de longo prazo
+e seus respectivos mantenedores:
+
+	https://www.kernel.org/category/releases.html
+
+A seleção de um kernel para suporte de longo prazo é puramente uma questão
+de um mantenedor ter a necessidade e o tempo para manter esse lançamento.
+Não há planos conhecidos para suporte de longo prazo para nenhum lançamento
+futuro específico.
+
+
+O Ciclo de Vida de um Patch
+---------------------------
+
+Os patches não vão diretamente do teclado do desenvolvedor para o kernel
+principal. Em vez disso, existe um processo um tanto complexo (embora um
+tanto informal) projetado para garantir que cada patch seja revisado quanto
+à sua qualidade e que cada patch implemente uma mudança que seja desejável
+ter no mainline. Esse processo pode acontecer rapidamente para correções
+menores ou, no caso de mudanças grandes e controversas, arrastar-se por
+anos. Grande parte da frustração dos desenvolvedores vem da falta de
+compreensão desse processo ou de tentativas de burlá-lo.
+
+Com a esperança de reduzir essa frustração, este documento descreverá como
+um patch entra no kernel. O que se segue abaixo é uma introdução que
+descreve o processo de uma forma um tanto idealizada. Um tratamento muito
+mais detalhado virá nas seções posteriores.
+
+As etapas pelas quais um patch passa são, geralmente:
+
+ - Design. É aqui que os requisitos reais para o patch e a forma
+   como esses requisitos serão atendidos são definidos. O trabalho de
+   design geralmente é feito sem envolver a comunidade, mas é melhor realizar
+   esse trabalho abertamente, se possível; isso pode economizar muito tempo
+   evitando ter que refazer o projeto mais tarde.
+
+ - Revisão inicial. Os patches são postados na lista de
+   discussão relevante, e os desenvolvedores dessa lista respondem com os
+   comentários que tiverem. Se tudo correr bem, esse processo deve apontar
+   qualquer problema grave no patch.
+
+ - Revisão ampla. Quando o patch estiver próximo de estar
+   pronto para inclusão no mainline, ele deve ser aceito por um mantenedor de
+   subsistema relevante — embora essa aceitação não seja uma garantia de que
+   o patch chegará até o kernel principal. O patch aparecerá na árvore de
+   subsistema do mantenedor e nas árvores -next. Quando o processo funciona,
+   esta etapa leva a uma revisão mais ampla do patch e à descoberta de
+   quaisquer problemas resultantes da integração deste patch com o trabalho
+   que está sendo feito por outros.
+
+ - Por favor, note que a maioria dos mantenedores também tem seus empregos
+   regulares, portanto, integrar o seu patch pode não ser a maior prioridade
+   deles. Se o seu patch estiver recebendo feedback sobre alterações que são
+   necessárias, você deve fazer essas alterações ou justificar por que elas
+   não devem ser feitas. Se o seu patch não tiver nenhuma objeção de revisão,
+   mas não estiver sendo integrado pelo mantenedor do subsistema ou driver
+   adequado, você deve ser persistente em atualizar o patch para o kernel
+   atual (garantindo que ele seja aplicado de forma limpa) e continuar
+   enviando-o para revisão e integração.
+
+ - Integração no mainline. Eventualmente, um
+   patch bem-sucedido será integrado ao repositório principal (*mainline*)
+   gerenciado por Linus Torvalds. Mais comentários e/ou problemas podem surgir
+   neste momento; é importante que o desenvolvedor seja responsivo a eles e
+   corrija quaisquer problemas que venham a aparecer.
+
+ - Lançamento estável. O número de usuários potencialmente
+   afetados pelo patch agora é grande, portanto, mais uma vez, novos
+   problemas podem surgir.
+
+ - Manutenção de longo prazo. Embora seja perfeitamente
+   possível para um desenvolvedor esquecer o código após integrá-lo, esse
+   tipo de comportamento tende a deixar uma má impressão na comunidade de
+   desenvolvimento. Integrar o código elimina parte do fardo de manutenção,
+   já que outros corrigirão problemas causados por mudanças de API. No entanto,
+   o desenvolvedor original deve continuar assumindo a responsabilidade pelo
+   código se ele quiser que este permaneça útil no longo prazo.
+
+Um dos maiores erros cometidos por desenvolvedores do kernel (ou por seus
+empregadores) é tentar reduzir todo o processo a uma única etapa de
+"integração no mainline". Essa abordagem invariavelmente leva à frustração
+de todos os envolvidos.
+
+Como os patches entram no Kernel
+--------------------------------
+
+Existe exatamente uma pessoa que pode integrar patches no repositório do
+kernel principal: Linus Torvalds. Mas, por exemplo, dos mais de 9.500 patches
+que entraram no kernel 2.6.38, apenas 112 (cerca de 1,3%) foram escolhidos
+diretamente pelo próprio Linus. O projeto do kernel há muito tempo cresceu
+para um tamanho onde nenhum desenvolvedor sozinho conseguiria inspecionar e
+selecionar cada patch sem ajuda. A maneira como os desenvolvedores do kernel
+lidaram com esse crescimento foi através do uso de um sistema de "tenentes"
+(*lieutenant system*) construído em torno de uma cadeia de confiança.
+
+A base de código do kernel é logicamente dividida em um conjunto de
+subsistemas: rede, suporte a arquiteturas específicas,
+gerenciamento de memória, dispositivos de vídeo, etc. A maioria dos
+subsistemas possui um mantenedor designado, um desenvolvedor que tem a
+responsabilidade geral pelo código dentro daquele subsistema. Esses
+mantenedores de subsistemas são os guardiões (de forma flexível)
+da parte do kernel que gerenciam; são eles que (geralmente) aceitarão um
+patch para inclusão no kernel principal.
+
+Cada um dos mantenedores de subsistemas gerencia sua própria versão da árvore
+de fontes do kernel, geralmente (mas certamente nem sempre) usando a
+ferramenta de gerenciamento de código-fonte Git. Ferramentas como o Git
+(e ferramentas relacionadas como o quilt ou mercurial) permitem que os
+mantenedores acompanhem uma lista de patches, incluindo informações de
+autoria e outros metadados. A qualquer momento, o mantenedor pode identificar
+quais patches em seu repositório não são encontrados no mainline.
+
+Quando a janela de integração se abre, os mantenedores de
+alto nível pedirão a Linus para realizar o pull de seus repositórios os patches
+que selecionaram para integração. Se Linus concordar, o fluxo de patches
+subirá para o seu repositório, tornando-se parte do kernel principal. A
+quantidade de atenção que Linus dedica a patches específicos
+recebidos em uma operação de pull varia. Está claro que, às vezes, ele os
+examina bem de perto. Mas, como regra geral, Linus confia que os mantenedores
+de subsistemas não enviarão patches ruins para o upstream.
+
+Os mantenedores de subsistemas, por sua vez, podem realizar o pull dos patches
+de outros mantenedores. Por exemplo, a árvore de rede é
+construída a partir de patches que se acumularam primeiro em árvores dedicadas
+a drivers de dispositivos de rede, rede sem fio, etc. Essa cadeia
+de repositórios pode ser arbitrariamente longa, embora raramente exceda dois
+ou três elos. Como cada mantenedor na cadeia confia naqueles que gerenciam as
+árvores de nível inferior, esse processo é conhecido como a "cadeia de
+confiança".
+
+Claramente, em um sistema como este, colocar patches no kernel depende de
+encontrar o mantenedor correto. Enviar patches diretamente para Linus
+normalmente não é o caminho certo a seguir.
+
+
+Árvore -next
+-------------
+
+A cadeia de árvores de subsistemas orienta o fluxo de patches para o kernel,
+mas também levanta uma questão interessante: e se alguém quiser dar uma
+olhada em todos os patches que estão sendo preparados para a próxima janela
+de integração? Os desenvolvedores estarão interessados em saber quais outras
+mudanças estão pendentes para ver se há conflitos com os quais se preocupar; um
+patch que altera o protótipo de uma função central do kernel, por exemplo,
+entrará em conflito com quaisquer outros patches que usem a forma mais antiga
+dessa função. Revisores e testadores querem ter acesso às mudanças em sua forma
+integrada antes que todas essas alterações cheguem ao kernel principal. Seria
+possível realizar o pull das mudanças de todas as árvores de subsistemas
+interessantes, mas isso seria um trabalho enorme e propenso a erros.
+
+A resposta vem na forma das árvores -next, onde as árvores de subsistemas
+são coletadas para testes e revisão. A mais antiga dessas árvores, mantida
+por Andrew Morton, é chamada de "-mm" (de *memory management*, gerenciamento
+de memória, que foi como ela começou). A árvore -mm integra patches de uma
+longa lista de árvores de subsistemas; ela também possui alguns patches
+destinados a ajudar na depuração (*debugging*).
+
+Além disso, a árvore -mm contém uma coleção significativa de patches que
+foram selecionados diretamente por Andrew. Esses patches podem ter sido
+postados em uma lista de discussão ou podem se aplicar a uma parte do kernel
+para a qual não existe uma árvore de subsistema designada. Como resultado, a
+-mm opera como uma espécie de árvore de subsistema de "último recurso"; se
+não houver outro caminho óbvio para um patch entrar no mainline, é provável
+que ele acabe na -mm. Patches diversos que se acumulam na
+-mm eventualmente serão encaminhados para uma árvore de subsistema adequada
+ou enviados diretamente para Linus. Em um ciclo de desenvolvimento típico,
+aproximadamente 5% a 10% do total de patches que entram no mainline chegam
+lá por meio da -mm.
+
+O patch -mm atual está disponível no diretório "mmotm" (*-mm of the moment*)
+em:
+
+	https://www.ozlabs.org/~akpm/mmotm/
+
+O uso da árvore MMOTM, no entanto, provavelmente será uma experiência
+frustrante; existe uma chance real de que ela sequer compile.
+
+A árvore primária para a integração de patches do próximo ciclo é a
+linux-next, mantida por Mark Brown. A árvore linux-next é, por design, um
+snapshot do que se espera que o mainline se pareça após o
+fechamento da próxima janela de integração. As árvores
+linux-next são anunciadas nas listas de discussão linux-kernel e linux-next
+quando são montadas; elas podem ser baixadas em:
+
+	https://www.kernel.org/pub/linux/kernel/next/
+
+A linux-next tornou-se uma parte integrante do processo de desenvolvimento
+do kernel; todos os patches integrados durante uma determinada janela de
+integração devem, idealmente, ter encontrado seu caminho para a linux-next algum
+tempo antes da abertura da janela de integração.
+
+
+Árvores de laboratório
+----------------------
+
+A árvore de fontes do kernel contém o diretório drivers/staging/, onde residem
+muitos subdiretórios para drivers ou sistemas de arquivos que estão a caminho
+de serem adicionados à árvore do kernel. Eles permanecem em drivers/staging/
+enquanto ainda precisam de mais trabalho; uma vez concluídos, podem ser movidos
+para o kernel proper Esta é uma maneira de acompanhar drivers que não estão à
+altura dos padrões de codificação ou de qualidade do kernel Linux, mas que as
+pessoas podem querer usar e acompanhar o desenvolvimento.
+
+Greg Kroah-Hartman atualmente mantém a árvore de staging. Os drivers que
+ainda precisam de trabalho são enviados a ele, com cada driver tendo seu
+próprio subdiretório em drivers/staging/. Junto com os arquivos de código-fonte
+do driver, um arquivo TODO também deve estar presente no diretório. O arquivo
+TODO lista o trabalho pendente que o driver precisa para ser aceito no kernel
+propriamente dito, bem como uma lista de pessoas que devem receber cópia
+(*Cc'd*) em quaisquer patches para o driver. As regras atuais exigem que os
+drivers contribuídos para o staging devem, no mínimo, compilar corretamente.
+
+O staging pode ser uma maneira relativamente fácil de colocar novos drivers
+no mainline onde, com sorte, eles chamarão a atenção de outros desenvolvedores
+e melhorarão rapidamente. No entanto, a entrada no staging não é o fim da
+história; o código no staging que não apresentar progresso regular será,
+eventualmente, removido. Os distribuidores também tendem a ser relativamente
+relutantes em habilitar drivers do staging. Portanto, o staging é, na melhor
+das hipóteses, uma parada no caminho para se tornar um driver mainline adequado.
+
+
+Ferramentas
+-----------
+
+Como pode ser visto no texto acima, o processo de desenvolvimento do kernel
+depende fortemente da capacidade de guiar coleções de patches em várias
+direções. Todo esse sistema não funcionaria nem de longe tão bem quanto
+funciona sem ferramentas adequadamente poderosas. Tutoriais sobre como usar
+essas ferramentas estão muito além do escopo deste documento, mas há espaço
+para algumas indicações.
+
+De longe, o sistema de gerenciamento de código-fonte dominante usado pela
+comunidade do kernel é o Git. O Git é um entre vários sistemas de controle
+de versão distribuídos desenvolvidos na comunidade de software livre. Ele é
+bem sintonizado para o desenvolvimento do kernel, uma vez que apresenta um
+excelente desempenho ao lidar com grandes repositórios e grandes volumes de
+patches. Ele também tem a reputação de ser difícil de aprender e usar, embora
+tenha melhorado ao longo do tempo. Algum tipo de familiaridade com o Git é
+quase um requisito para os desenvolvedores do kernel; mesmo que não o usem
+em seu próprio trabalho, eles precisarão do Git para acompanhar o que outros
+desenvolvedores (e o mainline) estão fazendo.
+
+O Git agora é empacotado por quase todas as distribuições Linux. Existe uma
+página inicial em:
+
+	https://git-scm.com/
+
+Essa página possui indicações para documentações e tutoriais.
+
+Entre os desenvolvedores do kernel que não usam o Git, a escolha mais popular
+é, quase certamente, o Mercurial:
+
+	https://www.selenic.com/mercurial/
+
+O Mercurial compartilha muitos recursos com o Git, mas oferece uma interface
+que muitos consideram mais fácil de usar.
+
+A outra ferramenta que vale a pena conhecer é o Quilt:
+
+	https://savannah.nongnu.org/projects/quilt/
+
+O Quilt é um sistema de gerenciamento de patches, em vez de um sistema de
+gerenciamento de código-fonte. Ele não rastreia o histórico ao longo do
+tempo; em vez disso, ele é orientado a rastrear um conjunto específico de
+alterações em relação a uma base de código em evolução. Alguns mantenedores
+de grandes subsistemas usam o Quilt para gerenciar patches destinados a ir
+para o upstream. Para o gerenciamento de certos tipos de árvores (-mm, por
+exemplo), o Quilt é a melhor ferramenta para o trabalho.
+
+
+Listas de discussão
+-------------------
+
+Uma grande parte do trabalho de desenvolvimento do kernel Linux é realizada por
+meio de listas de discussão. É difícil ser um membro plenamente ativo da
+comunidade sem se inscrever em pelo menos uma lista em algum lugar. No entanto,
+as listas de discussão do Linux também representam um risco potencial para os
+desenvolvedores, que correm o risco de serem soterrados por uma avalanche de
+e-mails, de violar as convenções utilizadas nas listas do Linux, ou ambos.
+
+A maioria das listas de discussão do kernel é hospedada no kernel.org; a
+lista mestre pode ser encontrada em:
+
+	https://subspace.kernel.org
+
+Existem listas hospedadas em outros locais; por favor, verifique o arquivo
+MAINTAINERS para encontrar a lista relevante para qualquer subsistema específico.
+
+A lista de discussão central para o desenvolvimento do kernel é, naturalmente,
+a linux-kernel. Esta lista é um lugar intimidador para se estar; o volume pode
+atingir 500 mensagens por dia, a quantidade de ruído é alta, a conversa pode
+ser severamente técnica e os participantes nem sempre estão preocupados em
+demonstrar um alto grau de polidez. No entanto, não há outro lugar onde a
+comunidade de desenvolvimento do kernel se reúna como um todo; desenvolvedores
+que evitam esta lista perderão informações importantes.
+
+Existem algumas dicas que podem ajudar na sobrevivência na lista linux-kernel:
+
+- Faça com que a lista seja entregue em uma pasta separada, em vez de na sua
+  caixa de entrada principal. É preciso ser capaz de ignorar o fluxo de e-mails
+  por períodos prolongados de tempo.
+
+- Não tente acompanhar cada conversa ninguém mais faz isso. É importante
+  filtrar tanto pelo tópico de interesse (embora note que conversas longas
+  podem se desviar do assunto original sem que a linha de assunto do e-mail
+  seja alterada) quanto pelas pessoas que estão participando.
+
+- Não alimente os trolls. Se alguém estiver tentando provocar uma resposta
+  irada, ignore-o.
+
+- Ao responder a um e-mail da lista linux-kernel (o mesmo valendo para outras
+  listas), preserve o cabeçalho Cc: para todos os envolvidos. Na ausência de um
+  motivo forte (como uma solicitação explícita), você nunca deve remover
+  destinatários. Sempre certifique-se de que a pessoa a quem você está
+  respondendo esteja na lista de Cc:. Essa convenção também torna desnecessário
+  solicitar explicitamente ser copiado em respostas às suas postagens.
+
+- Pesquise nos arquivos da lista (e na internet como um todo) antes de fazer
+  perguntas. Alguns desenvolvedores podem ficar impacientes com pessoas que
+  claramente não fizeram sua lição de casa.
+
+- Use respostas intercaladas, o que torna sua resposta mais fácil
+  de ler. (ou seja, evite o "top-posting" — a prática de colocar sua resposta
+  acima do texto citado ao qual você está respondendo). Para mais detalhes, veja
+  :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`.
+
+- Pergunte na lista de discussão correta. A lista linux-kernel pode até ser o
+  ponto de encontro geral, mas não é o melhor lugar para encontrar desenvolvedores
+  de todos os subsistemas.
+
+O último ponto, encontrar a lista de discussão correta  é um lugar comum
+onde os desenvolvedores iniciantes costumam errar. Alguém que faça uma pergunta
+relacionada a redes na lista linux-kernel quase certamente receberá uma
+sugestão educada para perguntar na lista netdev em seu lugar, já que essa é a
+lista frequentada pela maioria dos desenvolvedores de redes. Existem outras
+listas para os subsistemas SCSI, video4linux, IDE, filesystem (sistemas de
+arquivos), etc. O melhor lugar para procurar por listas de discussão é no
+arquivo MAINTAINERS empacotado junto com o código-fonte do kernel.
+
+
+Começando com o desenvolvimento do kernel
+-----------------------------------------
+
+Perguntas sobre como começar com o processo de desenvolvimento do kernel são
+comuns — tanto por parte de indivíduos quanto de empresas. Igualmente comuns
+são os passos em falso que tornam o início do relacionamento mais difícil do
+que precisa ser.
+
+As empresas frequentemente buscam contratar desenvolvedores bem conhecidos para
+dar o pontapé inicial em um grupo de desenvolvimento. Esta pode, de fato, ser
+uma técnica eficaz. No entanto, ela também tende a ser cara e não faz muito para
+expandir o grupo de desenvolvedores de kernel experientes. É possível capacitar
+desenvolvedores internos no desenvolvimento do kernel Linux, desde que haja o
+investimento de um pouco de tempo. Dedicar esse tempo pode dotar um empregador
+de um grupo de desenvolvedores que entendem tanto o kernel quanto a própria
+empresa, e que também podem ajudar a treinar outros. A médio prazo, esta é
+frequentemente a abordagem mais lucrativa.
+
+Desenvolvedores individuais frequentemente, e de forma compreensível, ficam sem
+saber por onde começar. Iniciar com um grande projeto pode ser intimidante;
+muitas vezes deseja-se testar o terreno com algo menor primeiro. Este é o ponto
+onde alguns desenvolvedores saltam para a criação de patches que corrigem erros
+de ortografia ou pequenos problemas de estilo de código. Infelizmente, tais
+patches criam um nível de ruído que distrai a comunidade de desenvolvimento
+como um todo, por isso, cada vez mais, eles são vistos com desdém. Novos
+desenvolvedores que desejam se apresentar à comunidade não receberão o tipo de
+recepção que desejam por esses meios.
+
+Andrew Morton dá este conselho para aspirantes a desenvolvedores do kernel:
+
+::
+
+  "O projeto número um para todos os iniciantes no kernel certamente deveria
+  ser 'certificar-se de que o kernel funcione perfeitamente o tempo todo em
+  todas as máquinas em que você conseguir colocar as mãos'. Normalmente, a
+  maneira de fazer isso é trabalhar com outros para resolver as coisas (isso
+  pode exigir persistência!), mas tudo bem — isso é parte do desenvolvimento
+  do kernel."
+
+(https://lwn.net/Articles/283982/).
+
+Na ausência de problemas óbvios para corrigir, os desenvolvedores são
+aconselhados a olhar para as listas atuais de regressões e bugs abertos em
+geral. Nunca há escassez de problemas que precisam de correção; ao abordar
+esses problemas, os desenvolvedores ganharão experiência com o processo
+enquanto, ao mesmo tempo, constroem respeito com o restante da comunidade de
+desenvolvimento.

linux-7.2.3/Documentation/translations/pt_BR/process/3.Early-stage.rst

@@ -0,0 +1,233 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Planejamento em estágio inicial
+===============================
+
+Ao contemplar um projeto de desenvolvimento do kernel Linux, pode ser tentador
+dar um salto direto e começar a codificar. No entanto, como ocorre com qualquer
+projeto significativo, grande parte da base para o sucesso é melhor estabelecida
+antes que a primeira linha de código seja escrita. Um tempo gasto no planejamento
+e na comunicação iniciais pode economizar muito mais tempo mais adiante.
+
+
+Especificando o problema
+------------------------
+
+Como qualquer projeto de engenharia, um aprimoramento bem-sucedido do kernel
+começa com uma descrição clara do problema a ser resolvido. Em alguns casos,
+esta etapa é fácil: quando um driver é necessário para um componente de
+hardware específico, por exemplo. Em outros, no entanto, é tentador confundir o
+problema real com a solução proposta, e isso pode levar a dificuldades.
+
+Considere um exemplo: alguns anos atrás, desenvolvedores que trabalhavam com o
+áudio do Linux buscavam uma maneira de executar aplicativos sem interrupções
+(*dropouts*) ou outros artefatos causados por latência excessiva no sistema. A
+solução a que chegaram foi um módulo do kernel destinado a se conectar à
+estrutura do Linux Security Module (LSM); esse módulo poderia ser configurado
+para dar a aplicativos específicos acesso ao escalonador de tempo real. Esse
+módulo foi implementado e enviado para a lista de discussão linux-kernel, onde
+imediatamente encontrou problemas.
+
+Para os desenvolvedores de áudio, esse módulo de segurança era suficiente para
+resolver o problema imediato deles. Para a comunidade mais ampla do kernel, no
+entanto, ele foi visto como um uso indevido da estrutura LSM (que não tem a
+intenção de conceder privilégios a processos que eles de outra forma não
+teriam) e um risco para a estabilidade do sistema. As soluções preferidas da
+comunidade envolviam o acesso ao escalonamento de tempo real via mecanismo
+rlimit a curto prazo, e o trabalho contínuo de redução de latência a longo prazo.
+
+A comunidade de áudio, no entanto, não conseguia enxergar além da solução
+específica que havia implementado; eles não estavam dispostos a aceitar
+alternativas. O desacordo resultante deixou esses desenvolvedores sentindo-se
+desiludidos com todo o processo de desenvolvimento do kernel; um deles voltou
+para uma lista de áudio e postou isto:
+
+  "Existe um bom número de desenvolvedores muito bons no kernel Linux, mas eles
+  tendem a ser abafados por uma grande multidão de tolos arrogantes. Tentar
+  comunicar os requisitos dos usuários a essas pessoas é uma perda de tempo.
+  Eles são 'inteligentes' demais para ouvir os meros mortais."
+
+(https://lwn.net/Articles/131776/).
+
+A realidade da situação era diferente; os desenvolvedores do kernel estavam muito
+mais preocupados com a estabilidade do sistema, com a manutenção a longo prazo e
+em encontrar a solução correta para o problema do que com um módulo específico.
+A moral da história é focar no problema — e não em uma solução específica — e
+discuti-lo com a comunidade de desenvolvimento antes de investir na criação de
+um conjunto de códigos.
+
+Portanto, ao contemplar um projeto de desenvolvimento do kernel, deve-se
+obter respostas para um pequeno conjunto de perguntas:
+
+ - Qual é, exatamente, o problema que precisa ser resolvido?
+
+ - Quem são os usuários afetados por esse problema? Quais casos de uso a
+   solução deve abranger?
+
+ - De que forma o kernel deixa a desejar em resolver esse problema atualmente?
+
+Só então faz sentido começar a considerar possíveis soluções.
+
+
+Discussão inicial
+-----------------
+
+Ao planejar um projeto de desenvolvimento do kernel, faz todo o sentido realizar
+discussões com a comunidade antes de iniciar a implementação. A comunicação
+inicial pode economizar tempo e problemas de várias maneiras:number of ways:
+
+ - Pode muito bem ser que o problema já seja tratado pelo kernel de maneiras
+   que você não compreendeu. O kernel Linux é grande e possui uma série de
+   recursos e capacidades que não são imediatamente óbvios. Nem todas as
+   capacidades do kernel são documentadas tão bem quanto se gostaria, e é fácil
+   deixar passar algumas coisas. Este autor já viu a postagem de um driver
+   completo que duplicava um driver existente do qual o novo autor não tinha
+   conhecimento. Códigos que reinventam as rodas existentes não são apenas um
+   desperdício; eles também não serão aceitos no kernel principal (*mainline*).
+
+ - Pode haver elementos na solução proposta que não serão aceitáveis para a
+   integração no kernel principal . É melhor descobrir problemas
+   como este antes de escrever o código.
+
+ - É inteiramente possível que outros desenvolvedores já tenham pensado sobre
+   o problema; eles podem ter ideias para uma solução melhor e podem estar
+   dispostos a ajudar na criação dessa solução.
+
+Anos de experiência com a comunidade de desenvolvimento do kernel ensinaram uma
+lição clara: códigos do kernel que são projetados e desenvolvidos a portas
+fechadas invariavelmente apresentam problemas que só são revelados quando o
+código é lançado na comunidade. Às vezes, esses problemas são graves, exigindo
+meses ou anos de esforço antes que o código possa ser adequado aos padrões da
+comunidade do kernel. Alguns exemplos incluem:
+
+ - A pilha de rede Devicescape foi projetada e implementada para sistemas
+   monoprocessados. Ela não pôde ser integrada ao kernel principal (*mainline*)
+   até que fosse adaptada para sistemas multiprocessados. Ajustar retroativamente
+   mecanismos de travamento (*locking*) e afins em um código é uma tarefa difícil;
+   como resultado, a integração desse código (hoje chamado mac80211) foi atrasada
+   por mais de um ano.
+
+ - O sistema de arquivos Reiser4 incluía uma série de capacidades que, na
+   opinião dos desenvolvedores principais do kernel, deveriam ter sido
+   implementadas na camada de sistema de arquivos virtual (*Virtual Filesystem*
+   ou VFS). Ele também incluía recursos que não podiam ser facilmente
+   implementados sem expor o sistema a travamentos mútuos (*deadlocks*) causados
+   pelo usuário. A revelação tardia desses problemas — e a recusa em corrigir
+   alguns deles — fez com que o Reiser4 permanecesse fora do kernel principal
+   (*mainline*).
+
+ - O módulo de segurança AppArmor fazia uso de estruturas de dados internas
+   do sistema de arquivos virtual de maneiras que eram
+   consideradas inseguras e não confiáveis. Essa preocupação (entre outras)
+   manteve o AppArmor fora do kernel principal (*mainline*) por anos.
+
+In each of these cases, a great deal of pain and extra work could have been
+avoided with some early discussion with the kernel developers.
+
+
+Como encontrar os mantenedores?
+-------------------------------
+
+Quando os desenvolvedores decidem tornar seus planos públicos, a próxima
+pergunta será: por onde começamos? A resposta é encontrar a(s) lista(s) de
+discussão correta(s) e o mantenedor adequado. Para listas de discussão, a
+melhor abordagem é procurar no arquivo MAINTAINERS por um local relevante para
+postar. Se houver uma lista de subsistema adequada, postar nela costuma ser
+preferível a postar na linux-kernel; é mais provável que você alcance
+desenvolvedores com experiência no subsistema relevante e o ambiente pode ser
+mais acolhedor.
+
+Encontrar os mantenedores pode ser um pouco mais difícil. Novamente, o arquivo
+MAINTAINERS é o lugar para começar. No entanto, esse arquivo tende a não estar
+sempre atualizado, e nem todos os subsistemas estão representados ali. A
+pessoa listada no arquivo MAINTAINERS pode, na verdade, não ser quem está
+atuando nessa função atualmente. Portanto, quando houver dúvidas sobre quem
+contactar, um truque útil é usar o git (e o "git log" em particular) para ver
+quem está ativo no momento dentro do subsistema de interesse. Observe quem
+está escrevendo os patches e quem, se houver alguém, está anexando linhas
+"Signed-off-by" a esses patches. Essas são as pessoas que estarão em melhor
+posição para ajudar com um novo projeto de desenvolvimento.
+
+A tarefa de encontrar o mantenedor correto às vezes é desafiadora o suficiente
+para que os desenvolvedores do kernel tenham adicionado um script para facilitar
+o processo:
+
+::
+
+	.../scripts/get_maintainer.pl
+
+Este script retornará o(s) mantenedor(es) atual(is) para um determinado arquivo
+ou diretório quando fornecida a opção "-f". Se receber um patch na linha de
+comando, ele listará os mantenedores que provavelmente devem receber cópias do
+patch. Esta é a maneira preferencial (ao contrário da opção "-f") de obter a
+lista de pessoas para incluir em cópia (Cc) nos seus patches. Há uma série de
+opções que regulam o quão profundamente o get_maintainer.pl buscará por
+mantenedores; por favor, tenha cuidado ao usar as opções mais agressivas, pois
+você pode acabar incluindo desenvolvedores que não têm interesse real no código
+que você está modificando.
+
+Se tudo mais falhar, falar com Andrew Morton pode ser uma maneira eficaz de
+rastrear um mantenedor para um trecho específico de código.
+
+
+Quando postar?
+--------------
+
+Se possível, postar seus planos durante os estágios iniciais só pode
+ser útil. Descreva o problema que está sendo resolvido e quaisquer
+planos que tenham sido feitos sobre como a implementação será feita.
+Qualquer informação que você possa fornecer pode ajudar a comunidade de
+desenvolvimento a dar contribuições úteis sobre o projeto.
+
+Uma coisa desanimadora que pode acontecer neste estágio não é uma
+reação hostil, mas, em vez disso, pouca ou nenhuma reação. A triste
+verdade sobre o assunto é que (1) os desenvolvedores do kernel tendem a
+estar ocupados, (2) não há escassez de pessoas com planos grandiosos e
+pouco código (ou mesmo perspectiva de código) para apoiá-los, e (3)
+ninguém é obrigado a revisar ou comentar sobre ideias postadas por
+outros. Além disso, designs de alto nível frequentemente escondem
+problemas que só são revelados quando alguém realmente tenta
+implementar esses designs; por essa razão, os desenvolvedores do kernel
+preferem ver o código.
+
+Se uma postagem de pedido de comentários (RFC) render poucos
+comentários, não presuma que isso significa que não há interesse no
+projeto. Infelizmente, você também não pode presumir que não há
+problemas com sua ideia. A melhor coisa a fazer nesta situação é
+prosseguir, mantendo a comunidade informada à medida que avança.
+
+
+Obter a aprovação oficial
+-------------------------
+
+Se o seu trabalho estiver sendo realizado em um ambiente corporativo  como é o
+caso da maior parte do trabalho no kernel do Linux —, você deve, obviamente, ter
+a permissão de gerentes devidamente autorizados antes de poder publicar os
+planos ou o código da sua empresa em uma lista de discussão pública.
+A publicação de código que não tenha sido liberado para lançamento sob uma
+licença compatível com a GPL pode ser especialmente problemática; quanto mais
+cedo a gerência e a equipe jurídica de uma empresa puderem entrar em acordo
+sobre a publicação de um projeto de desenvolvimento do kernel, melhor será para
+todos os envolvidos.
+
+Alguns leitores podem estar pensando, neste ponto, que o seu trabalho no kernel
+se destina a dar suporte a um produto que ainda não tem uma existência oficialmente
+reconhecida. Revelar os planos de seu empregador em uma lista de discussão pública
+pode não ser uma opção viável. Em casos como esse, vale a pena considerar se o
+segredo é realmente necessário; muitas vezes não há uma real necessidade de manter
+os planos de desenvolvimento a portas fechadas.
+
+Dito isso, também existem casos em que uma empresa legitimamente não pode
+revelar seus planos logo no início do processo de desenvolvimento. Empresas com
+desenvolvedores de kernel experientes podem optar por prosseguir de maneira isolada
+(em "malha aberta"), partindo do pressuposto de que serão capazes de evitar problemas
+graves de integração mais tarde. Para empresas que não possuem esse tipo de expertise
+interna, a melhor opção costuma ser a contratação de um desenvolvedor externo para
+revisar os planos sob um acordo de confidencialidade (NDA). A Linux Foundation opera
+um programa de NDA projetado para ajudar nesse tipo de situação; mais informações
+podem ser encontradas em:
+
+    https://www.linuxfoundation.org/nda/
+
+Esse tipo de revisão costuma ser suficiente para evitar problemas graves mais
+tarde, sem a necessidade de uma divulgação pública do projeto.

linux-7.2.3/Documentation/translations/pt_BR/process/changes.rst

@@ -0,0 +1,576 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+
+Requisitos mínimos para compilar o Kernel
+++++++++++++++++++++++++++++++++++++++++++
+
+Introdução
+===========
+
+Este documento foi projetado para fornecer uma lista das versões mínimas
+de software necessárias para executar a versão atual do kernel.
+
+Este documento é originalmente baseado no meu arquivo 'Changes' para os kernels
+2.0.x e portanto, deve créditos às mesmas pessoas que aquele arquivo (Jared
+Mauch, Axel Boldt, Alessandro Sigala e inúmeros outros usuários em toda a rede).
+
+Requisitos Mínimos Atuais
+****************************
+
+Atualize para pelo menos estas revisões de software antes de pensar que
+encontrou um bug! Se não tiver certeza de qual versão está executando atualmente
+, o comando sugerido deve lhe informar. Para uma lista dos programas em seu
+sistema, incluindo as versões, execute ./scripts/ver_linux.
+
+Novamente, tenha em mente que esta lista pressupõe que você já possui um kernel
+Linux em execução funcional. Além disso, nem todas as ferramentas são
+necessárias em todos os sistemas; obviamente, se você não possui nenhum hardware
+PC Card por exemplo, provavelmente não precisará se preocupar com o pcmciautils.
+
+====================== ===============  ========================================
+Programa               Versão mínima    Comando para verificar a versão
+====================== ===============  ========================================
+GNU C                  8.1              gcc --version
+Clang/LLVM (optional)  17.0.1           clang --version
+Rust (optional)        1.85.0           rustc --version
+bindgen (optional)     0.71.1           bindgen --version
+GNU make               4.0              make --version
+bash                   4.2              bash --version
+binutils               2.30             ld -v
+flex                   2.5.35           flex --version
+gdb                    7.2              gdb --version
+bison                  2.0              bison --version
+pahole                 1.22             pahole --version
+util-linux             2.10o            mount --version
+kmod                   13               kmod -V
+e2fsprogs              1.41.4           e2fsck -V
+jfsutils               1.1.3            fsck.jfs -V
+xfsprogs               2.6.0            xfs_db -V
+squashfs-tools         4.0              mksquashfs -version
+btrfs-progs            0.18             btrfs --version
+pcmciautils            004              pccardctl -V
+quota-tools            3.09             quota -V
+PPP                    2.4.0            pppd --version
+nfs-utils              1.0.5            showmount --version
+procps                 3.2.0            ps --version
+udev                   081              udevadm --version
+grub                   0.93             grub --version || grub-install --version
+mcelog                 0.6              mcelog --version
+iptables               1.4.2            iptables -V
+openssl & libcrypto    1.0.0            openssl version
+bc                     1.06.95          bc --version
+Sphinx [#f1]_          3.4.3            sphinx-build --version
+GNU tar                1.28             tar --version
+gtags (opcional)       6.6.5            gtags --version
+mkimage (opcional)     2017.01          mkimage --version
+Python                 3.9.x            python3 --version
+GNU AWK (opcional)     5.1.0            gawk --version
+====================== ===============  ========================================
+
+.. [#f1] O Sphinx é necessário apenas para gerar a documentação do Kernel.
+
+Compilação do Kernel
+*********************
+
+GCC
+---
+
+Os requisitos da versão do gcc podem variar dependendo do tipo de CPU
+do seu computador.
+
+Clang/LLVM (opcional)
+---------------------
+
+A versão formal mais recente do clang e dos utilitários LLVM (de acordo com
+`releases.llvm.org <https://releases.llvm.org>`_) é suportada para a compilação
+de kernels. Versões anteriores não têm funcionamento garantido, e poderemos
+remover do kernel soluções de contorno (workarounds) que eram utilizadas para
+suportar versões mais antigas. Por favor, veja a documentação adicional em
+:ref:`Building Linux with Clang/LLVM <kbuild_llvm>`.
+
+Rust (opcional)
+---------------
+
+É necessária uma versão recente do compilador Rust.
+
+Por favor, consulte Documentation/rust/quick-start.rst para obter instruções
+sobre como atender aos requisitos de compilação do suporte a Rust. Em
+particular, o alvo (target) rustavailable do Makefile é útil para verificar por
+que a cadeia de ferramentas (toolchain) Rust pode não estar sendo detectada.
+
+bindgen (opcional)
+------------------
+
+O ``bindgen`` é utilizado para gerar os vínculos (bindings) Rust para o lado C
+do kernel. Ele depende da ``libclang``.
+
+Make
+----
+
+Você precisará do GNU make 4.0 ou superior para compilar o kernel.
+
+Bash
+----
+
+Alguns scripts bash são usados para a compilação do kernel.
+É necessário o Bash 4.2 ou mais recente.
+
+Binutils
+--------
+
+O binutils 2.30 ou mais recente é necessário para compilar o kernel.
+
+pkg-config
+----------
+
+O sistema de compilação, a partir da versão 4.18, requer o pkg-config para
+verificar as ferramentas kconfig instaladas e para determinar as configurações
+de flags para uso em 'make {g,x}config'. Anteriormente, o pkg-config já era
+utilizado, mas não era verificado nem documentado.
+
+Flex
+----
+
+Desde o Linux 4.16, o sistema de compilação gera analisadores léxicos durante a
+compilação. Isso requer o flex 2.5.35 ou superior.
+
+
+Bison
+-----
+
+Desde o Linux 4.16, o sistema de compilação gera analisadores sintáticos durante
+a compilação. Isso requer o bison 2.0 ou superior
+
+pahole
+------
+
+Desde o Linux 5.2, se CONFIG_DEBUG_INFO_BTF estiver selecionado, o sistema de
+compilação gera BTF (BPF Type Format) a partir do DWARF no vmlinux, e um pouco
+depois para os módulos do kernel também. Isso requer o pahole v1.22 ou superior.
+
+Ele pode ser encontrado nos pacotes ``dwarves`` ou ``pahole`` das
+distribuições, ou em https://fedorapeople.org/~acme/dwarves/.
+
+Perl
+----
+
+Você precisará do perl 5 e dos seguintes módulos: ``Getopt::Long``,
+``Getopt::Std``, ``File::Basename`` e ``File::Find`` para compilar o kernel.
+
+Python
+------
+
+Várias opções de configuração o exigem: ele é necessário para as configurações
+padrão (defconfigs) de arm/arm64, CONFIG_LTO_CLANG, algumas configurações
+opcionais de DRM, a ferramenta kernel-doc e a geração da documentação (Sphinx),
+entre outros.
+
+BC
+--
+
+Você precisará do bc para compilar kernels 3.10 ou superior.
+
+
+OpenSSL
+-------
+
+A assinatura de módulos e a manipulação de certificados externos utilizam o
+programa OpenSSL e a biblioteca de criptografia para realizar a criação de
+chaves e a geração de assinaturas.
+
+Você precisará do openssl para compilar kernels 3.7 e superiores se a assinatura
+de módulos estiver habilitada. Você também precisará dos pacotes de
+desenvolvimento do openssl para compilar kernels 4.3 e superiores.
+
+Tar
+---
+
+O GNU tar é necessário caso você deseje habilitar o acesso aos cabeçalhos do
+kernel via sysfs (CONFIG_IKHEADERS).
+
+gtags / GNU GLOBAL (optional)
+-----------------------------
+
+A compilação do kernel requer o GNU GLOBAL versão 6.6.5 ou superior para gerar
+arquivos de tags através de make gtags. Isso se deve ao uso da flag ``-C
+(--directory)`` pelo ``gtags``.
+
+mkimage
+-------
+
+Esta ferramenta é utilizada ao gerar uma Flat Image Tree (FIT), comumente usada
+em plataformas ARM. A ferramenta está disponível através do pacote ``u-boot-tools``
+ou pode ser compilada a partir do código-fonte do U-Boot. Veja as instruções em
+https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
+
+GNU AWK
+-------
+
+O GNU AWK é necessário caso você deseje que a compilação do kernel gere dados de
+intervalo de endereços para
+módulos integrados (CONFIG_BUILTIN_MODULE_RANGES).
+
+Utilitários de sistema
+***********************
+
+Mudanças de arquitetura
+------------------------
+
+O DevFS tornou-se obsoleto em favor do udev
+(https://www.kernel.org/pub/linux/utils/kernel/hotplug/)
+
+O suporte a UIDs de 32 bits já está implementado. Divirta-se!
+
+A documentação das funções do Linux está migrando para a documentação embutida
+(inline), por meio de comentários com formatação especial próximos às suas
+definições no código-fonte. Esses comentários podem ser combinados com arquivos
+ReST no diretório Documentation/ para criar uma documentação enriquecida, que
+pode então ser convertida para arquivos PostScript, HTML, LaTeX, ePUB e PDF.
+Para converter do formato ReST para o formato de sua escolha, você precisará do
+Sphinx.
+
+Util-linux
+----------
+
+Novas versões do util-linux oferecem suporte no ``fdisk`` para discos maiores,
+suporte a novas opções para o mount, reconhecimento de mais tipos de partição e
+outras funcionalidades interessantes. Você provavelmente vai querer atualizar.
+
+Ksymoops
+--------
+
+Se o impensável acontecer e o seu kernel sofrer um oops, você pode precisar da
+ferramenta ksymoops para decodificá-lo, mas na maioria dos casos, não será
+necessário. É geralmente preferível compilar o kernel com ``CONFIG_KALLSYMS`` para
+que ele produza dumps legíveis que possam ser usados no estado em que se
+encontram (isso também gera uma saída melhor do que a do ksymoops).
+Se por algum motivo o seu kernel não for compilado com ``CONFIG_KALLSYMS`` e você
+não tiver como recompilar e reproduzir o oops com essa opção, você ainda poderá
+decodificá-lo com o ksymoops.
+
+Mkinitrd
+--------
+
+Estas mudanças no layout da árvore de arquivos ``/lib/modules`` também exigem que o
+mkinitrd seja atualizado.
+
+E2fsprogs
+---------
+
+A versão mais recente do ``e2fsprogs`` corrige diversos bugs no fsck e no debugfs.
+Obviamente, é uma boa ideia atualizar.
+
+JFSutils
+--------
+
+O pacote jfsutils contém os utilitários para o sistema de arquivos. Os seguintes
+utilitários estão disponíveis:
+
+- ``fsck.jfs`` - inicia a reprodução (replay) do log de transações, além de
+  verificar e reparar uma partição formatada em JFS.
+
+- ``mkfs.jfs`` - cria uma partição formatada em JFS.
+
+Outros utilitários de sistema de arquivos também estão disponíveis neste pacote.
+
+Xfsprogs
+--------
+
+A versão mais recente do ``xfsprogs`` contém os utilitários ``mkfs.xfs``,
+``xfs_db`` e ``xfs_repair``, entre outros, para o sistema de arquivos XFS. Ele é
+independente de arquitetura e qualquer versão a partir da 2.0.0 deve funcionar
+corretamente com esta versão do código do kernel XFS (recomenda-se a
+versão 2.6.0 ou posterior, devido a algumas melhorias significativas).
+
+PCMCIAutils
+-----------
+
+O PCMCIAutils substitui o pcmcia-cs. Ele configura corretamente os sockets
+PCMCIA na inicialização do sistema e carrega os módulos apropriados para
+dispositivos PCMCIA de 16 bits, caso o kernel esteja modularizado e o subsistema
+de hotplug seja utilizado.
+
+Quota-tools
+-----------
+
+O suporte a UIDs e GIDs de 32 bits é necessário caso você deseje utilizar o
+formato de cota versão 2 mais recente. O quota-tools versão 3.07 e superiores
+possuem esse suporte. Utilize a versão recomendada ou superior da tabela acima.
+
+Intel IA32 microcode
+--------------------
+
+Um driver foi adicionado para permitir a atualização do microcódigo Intel IA32,
+acessível como um dispositivo de caracteres comum (misc). Se você não estiver
+usando o udev, você poderá precisar de::
+
+  mkdir /dev/cpu
+  mknod /dev/cpu/microcode c 10 184
+  chmod 0644 /dev/cpu/microcode
+
+você poderá precisar executar os comandos
+acima como root antes de poder usar isso. Você provavelmente também desejará
+obter o utilitário de espaço de usuário ``microcode_ctl`` para utilizar em
+conjunto com este driver.
+
+udev
+----
+
+O udev é uma aplicação de espaço de usuário para popular o diretório /dev
+dinamicamente, apenas com entradas para dispositivos de fato presentes no
+sistema. O udev substitui a funcionalidade básica do devfs, permitindo ao mesmo
+tempo a nomeação persistente de dispositivos.
+
+FUSE
+----
+
+Necessita do libfuse 2.4.0 ou posterior. O mínimo absoluto é a versão 2.3.0,
+mas as opções de montagem direct_io e kernel_cache não funcionarão.
+
+Redes
+******
+
+Mudanças gerais
+----------------
+
+Caso você tenha necessidades avançadas de configuração de rede, você deve
+provavelmente considerar o uso das ferramentas de rede do iproute2.
+
+Filtro de Pacotes / NAT
+------------------------
+
+O código de filtragem de pacotes e NAT utiliza as mesmas ferramentas da série
+anterior de kernels 2.4.x (iptables). Ele ainda inclui módulos de
+retrocompatibilidade para o ipchains (estilo 2.2.x) e o ipfwadm (estilo 2.0.x).
+
+PPP
+---
+
+O driver PPP foi reestruturado para suportar multilink e permitir que opere
+sobre diversas camadas de mídia. Se você utiliza PPP, atualize o pppd para, no
+mínimo, a versão 2.4.0.
+
+Se você não estiver usando o udev, você deve possuir o arquivo de dispositivo
+``/dev/ppp``, o qual pode ser criado por::
+
+  mknod /dev/ppp c 108 0
+
+como root.
+
+NFS-utils
+---------
+
+Em kernels antigos (2.4 e anteriores), o servidor NFS precisava conhecer
+qualquer cliente que pretendesse acessar arquivos via NFS. Essa informação era
+fornecida ao kernel pelo mountd quando o cliente montava o sistema de arquivos,
+ou pelo exportfs na inicialização do sistema. O exportfs obtinha informações
+sobre clientes ativos a partir de /var/lib/nfs/rmtab.
+
+Esta abordagem é bastante frágil, pois depende da integridade do rmtab, o que
+nem sempre é fácil, particularmente ao tentar implementar fail-over. Mesmo
+quando o sistema está funcionando bem, o rmtab sofre com o acúmulo de muitas
+entradas antigas que nunca são removidas.
+
+Com kernels modernos, temos a opção de fazer o kernel informar ao mountd quando
+recebe uma requisição de um host desconhecido, permitindo que o mountd forneça
+as informações de exportação apropriadas ao kernel. Isso remove a dependência do
+rmtab e significa que o kernel só precisa conhecer os clientes ativos no
+momento.
+
+Para habilitar esta nova funcionalidade, você precisa::
+
+  mount -t nfsd nfsd /proc/fs/nfsd
+
+antes de executar o exportfs ou o mountd. Recomenda-se que todos os serviços NFS
+sejam protegidos da internet em geral por um firewall, sempre que possível.
+
+mcelog
+------
+
+Em kernels x86, o utilitário mcelog é necessário para processar e registrar
+eventos de machine check quando opção CONFIG_X86_MCE está ativada. Eventos de
+machine check são erros relatados pela CPU. O processamento desses eventos é
+fortemente recomendado.
+
+Documentação do Kernel
+***********************
+
+Sphinx
+------
+
+Por favor, consulte Documentation/doc-guide/sphinx.rst para detalhes sobre os
+requisitos do Sphinx.
+
+rustdoc
+-------
+
+O rustdoc é utilizado para gerar a documentação para código Rust. Por favor,
+consulte Documentation/rust/general-information.rst para mais informações.
+
+Obtendo software atualizado
+============================
+
+Compilação do kernel
+**********************
+
+gcc
+---
+
+- <ftp://ftp.gnu.org/gnu/gcc/>
+
+Clang/LLVM
+----------
+
+- :ref:`Getting LLVM <getting_llvm>`.
+
+Rust
+----
+
+- Documentation/rust/quick-start.rst.
+
+bindgen
+-------
+
+- Documentation/rust/quick-start.rst.
+
+Make
+----
+
+- <ftp://ftp.gnu.org/gnu/make/>
+
+Bash
+----
+
+- <ftp://ftp.gnu.org/gnu/bash/>
+
+Binutils
+--------
+
+- <https://www.kernel.org/pub/linux/devel/binutils/>
+
+Flex
+----
+
+- <https://github.com/westes/flex/releases>
+
+Bison
+-----
+
+- <ftp://ftp.gnu.org/gnu/bison/>
+
+OpenSSL
+-------
+
+- <https://www.openssl.org/>
+
+System utilities
+****************
+
+Util-linux
+----------
+
+- <https://www.kernel.org/pub/linux/utils/util-linux/>
+
+Kmod
+----
+
+- <https://www.kernel.org/pub/linux/utils/kernel/kmod/>
+- <https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git>
+
+Ksymoops
+--------
+
+- <https://www.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/>
+
+Mkinitrd
+--------
+
+- <https://code.launchpad.net/initrd-tools/main>
+
+E2fsprogs
+---------
+
+- <https://www.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/>
+- <https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/>
+
+JFSutils
+--------
+
+- <https://jfs.sourceforge.net/>
+
+Xfsprogs
+--------
+
+- <https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git>
+- <https://www.kernel.org/pub/linux/utils/fs/xfs/xfsprogs/>
+
+Pcmciautils
+-----------
+
+- <https://www.kernel.org/pub/linux/utils/kernel/pcmcia/>
+
+Quota-tools
+-----------
+
+- <https://sourceforge.net/projects/linuxquota/>
+
+
+Intel P6 microcode
+------------------
+
+- <https://downloadcenter.intel.com/>
+
+udev
+----
+
+- <https://www.freedesktop.org/software/systemd/man/udev.html>
+
+FUSE
+----
+
+- <https://github.com/libfuse/libfuse/releases>
+
+mcelog
+------
+
+- <https://www.mcelog.org/>
+
+Redes
+******
+
+PPP
+---
+
+- <https://download.samba.org/pub/ppp/>
+- <https://git.ozlabs.org/?p=ppp.git>
+- <https://github.com/paulusmack/ppp/>
+
+NFS-utils
+---------
+
+- <https://sourceforge.net/project/showfiles.php?group_id=14>
+- <https://nfs.sourceforge.net/>
+
+Iptables
+--------
+
+- <https://netfilter.org/projects/iptables/index.html>
+
+Ip-route2
+---------
+
+- <https://www.kernel.org/pub/linux/utils/net/iproute2/>
+
+OProfile
+--------
+
+- <https://oprofile.sf.net/download/>
+
+Kernel documentation
+********************
+
+Sphinx
+------
+
+- <https://www.sphinx-doc.org/>

linux-7.2.3/Documentation/translations/pt_BR/process/conclave.rst

@@ -0,0 +1,40 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Continuidade do projeto do kernel Linux
+=======================================
+
+O projeto de desenvolvimento do kernel Linux é amplamente distribuído, com mais de
+100 mantenedores, cada um trabalhando para manter as mudanças fluindo através de
+seus próprios repositórios. A etapa final, no entanto, é centralizada, onde as
+mudanças são puxadas para o repositório mainline. Isso é normalmente feito por
+Linus Torvalds mas, como foi demonstrado pelo lançamento da versão 4.19 em 2018,
+existem outros que podem realizar esse trabalho quando surge a necessidade.
+
+Caso os mantenedores desse repositório se tornem indispostos ou incapazes de
+realizar esse trabalho daqui em diante (incluindo a facilitação de uma transição),
+o projeto precisará encontrar um ou mais substitutos sem demora. O processo pelo
+qual isso será feito está listado abaixo. O $ORGANIZER é o último organizador do
+Maintainer Summit ou o atual presidente do Conselho Consultivo Técnico (TAB) da
+Linux Foundation (LF) como reserva.
+
+- Em até 72 horas, o $ORGANIZER abrirá uma discussão com os convidados do
+  Maintainer Summit concluído mais recentemente. Uma reunião desses convidados e
+  do TAB, seja online ou presencial, será agendada o mais rápido possível de uma
+  forma que maximize o número de pessoas que possam participar.
+
+- Se não houver ocorrido um Maintainer Summit nos últimos 15 meses, o conjunto de
+  convidados para esta reunião será determinado pelo TAB.
+
+- Os convidados para esta reunião podem trazer outros mantenedores conforme
+  necessário.
+
+- Esta reunião, presidida pelo $ORGANIZER, considerará opções para a gestão
+  contínua do repositório de nível superior do kernel, de forma consistente com
+  a expectativa de maximizar a saúde a longo prazo do projeto e de sua comunidade.
+
+- Em até duas semanas, um representante deste grupo comunicará à comunidade em
+  geral, utilizando a lista de discussão ksummit@lists.linux.dev, quais serão os
+  próximos passos.
+
+A Linux Foundation, conforme orientada pelo TAB, tomará as medidas necessárias
+para apoiar e implementar este plano.

linux-7.2.3/Documentation/translations/pt_BR/process/development-process.rst

@@ -0,0 +1,22 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Guia para o Processo de Desenvolvimento do Kernel
+=================================================
+
+O objetivo deste documento é ajudar desenvolvedores (e seus gerentes)
+a trabalhar com a comunidade de desenvolvimento com o mínimo de frustração.
+É uma tentativa de documentar como esta comunidade funciona de uma forma
+que seja acessível àqueles que não estão intimamente familiarizados com o
+desenvolvimento do kernel Linux (ou, de fato, com o desenvolvimento de
+software livre em geral). Embora haja algum material técnico aqui, esta
+é fundamentalmente uma discussão orientada ao processo, que não requer um
+conhecimento profundo de programação de kernel para ser compreendida.
+
+.. toctree::
+   :caption: Contents
+   :numbered:
+   :maxdepth: 2
+
+   1.Intro
+   2.Process
+   3.Early-stage

linux-7.2.3/Documentation/translations/pt_BR/process/howto.rst

@@ -0,0 +1,637 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _pt_process_howto:
+
+COMO FAZER o desenvolvimento do kernel Linux
+============================================
+
+Este é o documento definitivo sobre este tópico. Ele contém instruções
+sobre como se tornar um desenvolvedor do kernel Linux e como aprender a
+trabalhar com a comunidade de desenvolvimento do kernel Linux. Ele tenta
+não conter nada relacionado aos aspectos técnicos da programação do kernel,
+mas ajudará a apontar a direção certa para isso.
+
+Se algo neste documento ficar desatualizado, por favor, envie patches para
+o mantenedor deste arquivo, que está listado no final do documento.
+
+
+Introdução
+------------
+
+Então, você quer aprender como se tornar um desenvolvedor do kernel Linux?
+Ou o seu gerente lhe disse: "Vá escrever um driver Linux para este
+dispositivo". O objetivo deste documento é ensinar tudo o que você precisa
+saber para conseguir isso, descrevendo o processo pelo qual você deve passar
+e oferecendo dicas sobre como trabalhar com a comunidade. Ele também tentará
+explicar algumas das razões pelas quais a comunidade trabalha da forma que
+trabalha.
+
+O kernel é escrito principalmente em C, com algumas partes dependentes de
+arquitetura escritas em assembly. Um bom entendimento de C é necessário para
+o desenvolvimento do kernel. O conhecimento de Assembly (de qualquer
+arquitetura) não é obrigatório, a menos que você planeje fazer
+desenvolvimento de baixo nível para essa arquitetura específica. Embora não
+sejam um substituto para uma formação sólida em C e/ou anos de experiência,
+os seguintes livros são bons para, no mínimo, referência:
+
+  - "The C Programming Language" por Kernighan e Ritchie [Prentice Hall]
+
+  - "Practical C Programming" por Steve Oualline [O'Reilly]
+
+  - "C: A Reference Manual" por Harbison e Steele [Prentice Hall]
+
+O kernel é escrito usando o GNU C e a GNU toolchain. Embora ele siga o
+padrão ISO C11, ele utiliza uma série de extensões que não estão presentes
+no padrão. O kernel é um ambiente C independente (freestanding), sem
+dependência da biblioteca C padrão (libc), portanto, algumas partes do
+padrão C não são suportadas. Divisões arbitrárias de "long long" e ponto
+flutuante não são permitidas. Às vezes, pode ser difícil entender as
+suposições que o kernel faz sobre a toolchain e as extensões que ele utiliza
+e, infelizmente, não existe uma referência definitiva para elas. Por favor,
+verifique as páginas de informações do gcc (`info gcc`) para obter algumas
+informações sobre elas.
+
+Por favor, lembre-se de que você está tentando aprender como trabalhar com a
+comunidade de desenvolvimento existente. É um grupo diversificado de pessoas,
+com altos padrões de codificação, estilo e procedimento. Esses padrões foram
+criados ao longo do tempo com base no que se descobriu funcionar melhor para
+uma equipe tão grande e geograficamente dispersa. Tente aprender o máximo
+possível sobre esses padrões com antecedência, pois eles estão bem
+documentados; não espere que as pessoas se adaptem a você ou à forma de fazer
+as coisas da sua empresa.
+
+
+Questões Legais
+---------------
+
+O código-fonte do kernel Linux é lançado sob a GPL. Por favor, veja o arquivo
+COPYING no diretório principal da árvore de fontes. As regras de licenciamento
+do kernel Linux e como usar os identificadores `SPDX <https://spdx.org/>`_ no
+código-fonte estão descritas em :ref:`Documentation/process/license-rules.rst <kernel_licensing>`.
+Se você tiver mais perguntas sobre a licença, por favor, entre em contato com
+um advogado e não pergunte na lista de discussão do kernel Linux. As pessoas
+nas listas de discussão não são advogados e você não deve confiar em suas
+declarações sobre assuntos jurídicos.
+
+Para perguntas e respostas comuns sobre a GPL, por favor, veja:
+
+        https://www.gnu.org/licenses/gpl-faq.html
+
+
+Documentação
+------------
+
+A árvore de fontes do kernel Linux possui uma vasta gama de documentos que
+são inestimáveis para aprender como interagir com a comunidade do kernel.
+Quando novos recursos são adicionados ao kernel, recomenda-se que novos
+arquivos de documentação também sejam adicionados explicando como usar o
+recurso. Quando uma mudança no kernel faz com que a interface que o kernel
+expõe para o espaço do usuário (userspace) mude, recomenda-se que você envie
+a informação ou um patch para as páginas de manual explicando a mudança para
+o mantenedor das páginas de manual em alx@kernel.org, e coloque em cópia (CC)
+a lista linux-api@vger.kernel.org.
+
+Aqui está uma lista de arquivos que estão na árvore de fontes do kernel e
+que são de leitura obrigatória:
+
+  :ref:`Documentation/admin-guide/README.rst <readme>`
+    Este arquivo fornece um breve histórico sobre o kernel Linux e descreve
+    o que é necessário fazer para configurar e compilar o kernel. Pessoas
+    que são novas no kernel devem começar por aqui.
+
+  :doc:`changes`
+    Este arquivo fornece uma lista das versões mínimas de vários pacotes de
+    software que são necessários para compilar e executar o kernel com
+    sucesso.
+
+  :ref:`Documentation/process/coding-style.rst <codingstyle>`
+    Este documento descreve o estilo de codificação do kernel Linux e parte
+    da fundamentação por trás dele. Espera-se que todo código novo siga as
+    diretrizes deste documento. A maioria dos mantenedores apenas aceitará
+    patches se essas regras forem seguidas, e muitas pessoas apenas
+    revisarão o código se ele estiver no estilo adequado.
+
+  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+    Este arquivo descreve em detalhes explícitos como criar e enviar
+    um patch com sucesso, incluindo (mas não limitado a):
+
+        - Conteúdo do e-mail
+        - Formato do e-mail
+        - Para quem enviá-lo
+
+    Seguir estas regras não garantirá o sucesso (já que todos os patches
+    estão sujeitos a um escrutínio de conteúdo e estilo), mas não segui-las
+    quase sempre o impedirá.
+
+Outras excelentes descrições de como criar patches adequadamente são:
+
+	"O Patch Perfeito"
+		https://www.ozlabs.org/~akpm/stuff/tpp.txt
+
+	"Formato de Submissão de Patch do Kernel Linux"
+		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
+
+  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
+    Este arquivo descreve a justificativa por trás da decisão consciente de
+    não ter uma API estável dentro do kernel, incluindo pontos como:
+
+      - Camadas de adaptação (shim-layers) de subsistemas (para compatibilidade?)
+      - Portabilidade de drivers entre sistemas operacionais.
+      - Mitigação de mudanças rápidas dentro da árvore de fontes do kernel
+        (ou impedimento de mudanças rápidas).
+
+    Este documento é crucial para compreender a filosofia de desenvolvimento
+    do Linux e é muito importante para pessoas que estão migrando para o
+    Linux vindas do desenvolvimento em outros Sistemas Operacionais.
+
+  :ref:`Documentation/process/security-bugs.rst <securitybugs>`
+    Se você acredita ter encontrado um problema de segurança no kernel Linux,
+    por favor, siga os passos descritos neste documento para ajudar a
+    notificar os desenvolvedores do kernel e auxiliar na resolução do problema.
+
+  :ref:`Documentation/process/management-style.rst <managementstyle>`
+    Este documento descreve como os mantenedores do kernel Linux operam e o
+    ethos compartilhado por trás de suas metodologias. Esta é uma leitura
+    importante para qualquer pessoa nova no desenvolvimento do kernel (ou
+    para qualquer pessoa simplesmente curiosa sobre isso), pois resolve muitos
+    equívocos comuns e confusões sobre o comportamento único dos mantenedores
+    do kernel.
+
+  :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+    Este arquivo descreve as regras sobre como ocorrem os lançamentos das
+    versões estáveis (stable) do kernel e o que fazer se você desejar que
+    uma alteração seja incluída em um desses lançamentos.
+
+  :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
+    Uma lista de documentação externa que pertence ao desenvolvimento do
+    kernel. Por favor, consulte esta lista caso não encontre o que está
+    procurando dentro da documentação interna do kernel.
+
+  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
+    Uma boa introdução descrevendo exatamente o que é um patch e como
+    aplicá-lo aos diferentes ramos (branches) de desenvolvimento do kernel.
+
+O kernel também possui um grande número de documentos que podem ser
+gerados automaticamente a partir do próprio código-fonte ou de
+marcações ReStructuredText (ReST), como esta. Isso inclui uma
+descrição completa da API interna do kernel e regras sobre como
+manipular o bloqueio (locking) corretamente.
+
+Todos esses documentos podem ser gerados em formato PDF ou HTML ao
+executar::
+
+	make pdfdocs
+	make htmldocs
+
+respectivamente, a partir do diretório principal do código-fonte do kernel.
+
+Os documentos que utilizam a marcação ReST serão gerados em
+Documentation/output. Eles também podem ser gerados nos formatos
+LaTeX e ePub com::
+
+	make latexdocs
+	make epubdocs
+
+Como se tornar um desenvolvedor do kernel
+------------------------------------------
+
+Se você não sabe nada sobre o desenvolvimento do kernel Linux, você deve
+consultar o projeto Linux KernelNewbies:
+
+	https://kernelnewbies.org
+
+Ele consiste em uma lista de discussão útil onde você pode fazer quase
+qualquer tipo de pergunta básica sobre o desenvolvimento do kernel
+(certifique-se de pesquisar nos arquivos primeiro, antes de perguntar
+algo que já foi respondido no passado). Ele também possui um canal de
+IRC que você pode usar para fazer perguntas em tempo real, e muita
+documentação útil para aprender sobre o desenvolvimento do kernel Linux.
+
+O site possui informações básicas sobre a organização do código,
+subsistemas e projetos atuais (tanto in-tree quanto out-of-tree).
+Também descreve algumas informações logísticas básicas, como por exemplo,
+como compilar um kernel e aplicar um patch.
+
+Se você não sabe por onde começar, mas deseja procurar alguma tarefa
+para iniciar sua integração na comunidade de desenvolvimento do kernel,
+acesse o projeto Linux Kernel Janitor:
+
+	https://kernelnewbies.org/KernelJanitors
+
+É um ótimo lugar para começar. Ele descreve uma lista de problemas
+relativamente simples que precisam ser limpos e corrigidos dentro da
+árvore de códigos-fonte do kernel Linux. Ao trabalhar com os
+desenvolvedores responsáveis por este projeto, você aprenderá o básico
+sobre como incluir seu patch na árvore do kernel Linux e,
+possivelmente, será orientado sobre o que trabalhar em seguida, caso
+ainda não tenha uma ideia.
+
+Antes de fazer qualquer modificação real no código do kernel Linux, é
+imperativo entender como o código em questão funciona. Para esse
+propósito, nada é melhor do que lê-lo diretamente (a maioria das partes
+complexas está bem comentada), talvez até com a ajuda de ferramentas
+especializadas. Uma ferramenta particularmente recomendada é o projeto
+Linux Cross-Reference, que é capaz de apresentar o código-fonte em um
+formato de página web indexada e auto-referenciada. Um excelente
+repositório atualizado do código do kernel pode ser encontrado em:
+
+    https://elixir.bootlin.com/
+
+
+O processo de desenvolvimento
+-----------------------------
+
+O processo de desenvolvimento do kernel Linux consiste atualmente em algumas
+"branches" (ramos) principais diferentes e muitos ramos de subsistemas
+específicos. Esses diferentes ramos são:
+
+  - Árvore principal (mainline) do Linus
+  - Várias árvores estáveis com múltiplos números de versão principal
+  - Árvores específicas de subsistemas
+  - Árvore de testes de integração linux-next
+
+Árvore principal (Mainline tree)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A árvore principal é mantida por Linus Torvalds e pode ser encontrada em
+https://kernel.org ou no repositório. Seu processo de desenvolvimento é
+o seguinte:
+
+  - Assim que um novo kernel é lançado, uma janela de duas semanas é aberta;
+    durante esse período, os mantenedores podem enviar grandes diffs para
+    Linus, geralmente patches que já foram incluídos na linux-next por algumas
+    semanas. A forma preferida de enviar grandes mudanças é usando o git
+    (a ferramenta de gerenciamento de código-fonte do kernel, mais informações
+    podem ser encontradas em https://git-scm.com/), mas patches simples
+    também são aceitos.
+  - Após duas semanas, um kernel -rc1 é lançado e o foco passa a ser tornar
+    o novo kernel o mais sólido possível. A maioria dos patches neste estágio
+    deve corrigir uma regressão. Bugs que sempre existiram não são regressões,
+    portanto, envie esses tipos de correções apenas se forem importantes.
+    Observe que um driver (ou sistema de arquivos) totalmente novo pode ser
+    aceito após o -rc1 porque não há risco de causar regressões com tal
+    mudança, desde que a alteração seja autocontida e não afete áreas fora do
+    código que está sendo adicionado. O git pode ser usado para enviar
+    patches para Linus após o lançamento do -rc1, mas os patches também
+    precisam ser enviados para uma lista de discussão pública para revisão.
+  - Um novo -rc é lançado sempre que Linus considerar que a árvore git atual
+    está em um estado razoavelmente estável e adequado para testes. O objetivo
+    é lançar um novo kernel -rc a cada semana.
+  - O processo continua até que o kernel seja considerado "pronto"; o
+    processo deve durar cerca de 6 semanas.
+
+Vale a pena mencionar o que Andrew Morton escreveu na lista de discussão
+do kernel Linux sobre os lançamentos do kernel:
+
+    *"Ninguém sabe quando um kernel será lançado, porque ele é
+    lançado de acordo com o status percebido dos bugs, não de acordo
+    com um cronograma pré-concebido."*
+
+Várias árvores estáveis com múltiplos números de versão principal
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Kernels com versões de 3 partes são kernels -stable (estáveis). Eles
+contêm correções relativamente pequenas e críticas para problemas de
+segurança ou regressões significativas descobertas em um determinado
+lançamento principal da árvore mainline. Cada lançamento em uma série
+estável principal incrementa a terceira parte do número da versão,
+mantendo as duas primeiras partes iguais.
+
+Este é o ramo recomendado para usuários que desejam o kernel estável
+mais recente e não estão interessados em ajudar a testar versões de
+desenvolvimento ou experimentais.
+
+As árvores estáveis são mantidas pela equipe "stable"
+<stable@vger.kernel.org> e são lançadas conforme a necessidade exigir.
+O período normal de lançamento é de aproximadamente duas semanas, mas
+pode ser mais longo se não houver problemas urgentes. Por outro lado,
+um problema relacionado à segurança pode fazer com que um lançamento
+ocorra quase instantaneamente.
+
+O arquivo :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+na árvore do kernel documenta quais tipos de mudanças são aceitáveis para
+a árvore -stable e como o processo de lançamento funciona.
+
+Árvores específicas de subsistemas
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Os mantenedores dos vários subsistemas do kernel — e também muitos
+desenvolvedores de subsistemas do kernel — expõem seu estado atual de
+desenvolvimento em repositórios de código-fonte. Dessa forma, outros
+podem ver o que está acontecendo nas diferentes áreas do kernel. Em
+áreas onde o desenvolvimento é rápido, um desenvolvedor pode ser
+solicitado a basear suas submissões em tal árvore de subsistema do
+kernel para que conflitos entre a submissão e outros trabalhos já em
+andamento sejam evitados.
+
+A maioria desses repositórios são árvores git, mas também existem outros
+SCMs em uso, ou filas de patches sendo publicadas como séries quilt. Os
+endereços desses repositórios de subsistemas estão listados no arquivo
+MAINTAINERS. Muitos deles podem ser navegados em https://git.kernel.org/.
+
+Antes que um patch proposto seja incluído em tal árvore de subsistema,
+ele está sujeito a uma revisão que ocorre principalmente em listas de
+discussão (veja a seção respectiva abaixo). Para vários subsistemas do
+kernel, este processo de revisão é rastreado com a ferramenta patchwork.
+O Patchwork oferece uma interface web que mostra as postagens de patches,
+quaisquer comentários sobre um patch ou revisões feitas a ele, e os
+mantenedores podem marcar os patches como "sob revisão", "aceitos" ou
+"rejeitados". A maioria desses sites patchwork está listada em
+https://patchwork.kernel.org/.
+
+Árvore de testes de integração linux-next
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Antes que as atualizações das árvores de subsistemas sejam mescladas na
+árvore mainline, elas precisam ser testadas quanto à integração. Para
+este propósito, existe um repositório de testes especial no qual
+praticamente todas as árvores de subsistemas são integradas (pulled)
+quase diariamente:
+
+    https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
+
+Dessa forma, a linux-next oferece uma visão resumida do que se espera
+que entre no kernel mainline no próximo período de mesclagem (merge
+window). Testadores aventureiros são muito bem-vindos para testar a
+linux-next em tempo de execução.
+
+
+Relato de Bugs
+--------------
+
+O arquivo 'Documentation/admin-guide/reporting-issues.rst' no diretório
+principal de códigos-fonte do kernel descreve como relatar um possível
+bug no kernel e detalha que tipo de informação é necessária para os
+desenvolvedores do kernel ajudarem a rastrear o problema.
+
+Gerenciando relatos de bugs
+---------------------------
+
+Uma das melhores maneiras de colocar em prática suas habilidades de hacking
+é corrigindo bugs relatados por outras pessoas. Você não apenas ajudará a
+tornar o kernel mais estável, mas também aprenderá a resolver problemas do
+mundo real, melhorará suas habilidades e outros desenvolvedores passarão a
+notar sua presença. Corrigir bugs é uma das melhores formas de obter mérito
+entre outros desenvolvedores, pois poucas pessoas gostam de gastar tempo
+corrigindo bugs de terceiros.
+
+Para trabalhar em relatos de bugs já existentes, encontre um subsistema no
+qual você esteja interessado. Verifique no arquivo MAINTAINERS para onde
+os bugs daquele subsistema são relatados; geralmente será uma lista de
+discussão, raramente um rastreador de bugs (bugtracker). Pesquise nos
+arquivos de mensagens do local indicado por relatos recentes e ajude onde
+achar apropriado. Você também pode verificar o site
+https://bugzilla.kernel.org para relatos de bugs; apenas alguns
+subsistemas do kernel o utilizam ativamente para relato ou rastreamento,
+entretanto, bugs de todo o kernel acabam sendo registrados lá.
+
+
+Listas de discussão
+-------------------
+
+Como alguns dos documentos acima descrevem, a maioria dos desenvolvedores
+do núcleo (core) do kernel participa da Linux Kernel Mailing List (LKML).
+Detalhes sobre como se inscrever e cancelar a inscrição na lista podem
+ser encontrados em:
+
+    https://subspace.kernel.org/subscribing.html
+
+Existem arquivos de mensagens da lista na web em muitos lugares diferentes.
+Use um mecanismo de busca para encontrar esses arquivos. Por exemplo:
+
+    https://lore.kernel.org/linux-kernel/
+
+É altamente recomendável que você pesquise nos arquivos sobre o tópico que
+deseja abordar antes de postar na lista. Muitas coisas já discutidas em
+detalhes estão registradas apenas nos arquivos das listas de discussão.
+
+A maioria dos subsistemas individuais do kernel também possui sua própria
+lista de discussão separada, onde realizam seus esforços de desenvolvimento.
+Consulte o arquivo MAINTAINERS para obter uma lista de quais são essas
+listas para os diferentes grupos.
+
+Muitas das listas estão hospedadas no kernel.org. Informações sobre elas
+podem ser encontradas em:
+
+    https://subspace.kernel.org
+
+Por favor, lembre-se de seguir bons hábitos de comportamento ao usar as
+listas. Embora um pouco clichê, a URL a seguir possui algumas diretrizes
+simples para interagir com a lista (ou qualquer outra lista):
+
+    https://subspace.kernel.org/etiquette.html
+
+Se várias pessoas responderem ao seu e-mail, a lista de destinatários em
+CC: pode se tornar bem grande. Não remova ninguém da lista CC: sem um
+bom motivo, e não responda apenas para o endereço da lista. Acostume-se
+a receber o e-mail duas vezes (um do remetente e outro da lista) e não
+tente ajustar isso adicionando cabeçalhos de e-mail complexos; as pessoas
+não gostarão disso.
+
+Lembre-se de manter o contexto e a atribuição de suas respostas intactos;
+mantenha as linhas do tipo "John Kernelhacker escreveu...:" no topo da
+sua resposta e adicione seus comentários entre as seções citadas
+individualmente, em vez de escrever tudo no topo do e-mail.
+
+Se você adicionar patches ao seu e-mail, certifique-se de que sejam texto
+puro legível, conforme declarado em
+:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
+Os desenvolvedores do kernel não querem lidar com anexos ou patches
+compactados; eles podem querer comentar linhas individuais do seu patch,
+o que só funciona dessa forma. Certifique-se de usar um programa de
+e-mail que não altere espaços e caracteres de tabulação (tabs). Um bom
+primeiro teste é enviar o e-mail para si mesmo e tentar aplicar o seu
+próprio patch. Se isso não funcionar, conserte seu programa de e-mail ou
+troque-o até que funcione.
+
+Acima de tudo, por favor, lembre-se de mostrar respeito aos outros
+inscritos.
+
+
+Trabalhando com a comunidade
+----------------------------
+
+O objetivo da comunidade do kernel é fornecer o melhor kernel possível.
+Quando você envia um patch para aceitação, ele será revisado por seus
+méritos técnicos e apenas por eles. Então, o que você deve esperar?
+
+  - críticas
+  - comentários
+  - solicitações de mudança
+  - solicitações de justificativa
+  - silêncio
+
+Lembre-se, isso faz parte do processo de incluir seu patch no kernel.
+Você deve ser capaz de aceitar críticas e comentários sobre seus patches,
+avaliá-los em nível técnico e retrabalhar seus patches ou fornecer
+raciocínios claros e concisos sobre o porquê de certas mudanças não
+deverem ser feitas. Se não houver respostas à sua postagem, aguarde
+alguns dias e tente novamente; às vezes, as coisas se perdem no enorme
+volume de mensagens.
+
+O que você não deve fazer?
+
+  - esperar que seu patch seja aceito sem questionamentos
+  - tornar-se defensivo
+  - ignorar comentários
+  - reenviar o patch sem fazer nenhuma das alterações solicitadas
+
+Em uma comunidade que busca a melhor solução técnica possível, sempre
+haverá opiniões divergentes sobre o quão benéfico é um patch. Você deve
+ser cooperativo e estar disposto a adaptar sua ideia para que ela se
+encaixe no kernel. Ou, pelo menos, estar disposto a provar que sua ideia
+vale a pena. Lembre-se: estar errado é aceitável, desde que você esteja
+disposto a trabalhar em direção a uma solução correta.
+
+É normal que as respostas ao seu primeiro patch sejam apenas uma lista
+de uma dúzia de coisas que você deve corrigir. Isso **não** implica que
+seu patch não será aceito e **não** é algo pessoal contra você. Simplesmente
+corrija todos os problemas apontados em seu patch e envie-o novamente.
+
+
+Diferenças entre a comunidade do kernel e estruturas corporativas
+-----------------------------------------------------------------
+
+A comunidade do kernel trabalha de forma diferente da maioria dos ambientes
+tradicionais de desenvolvimento corporativo. Aqui está uma lista de coisas
+que você pode tentar fazer para evitar problemas:
+
+  Boas coisas a dizer em relação às suas mudanças propostas:
+
+    - "Isto resolve múltiplos problemas."
+    - "Isto remove 2000 linhas de código."
+    - "Aqui está um patch que explica o que estou tentando descrever."
+    - "Eu testei isso em 5 arquiteturas diferentes..."
+    - "Aqui está uma série de pequenos patches que..."
+    - "Isto aumenta a performance em máquinas comuns..."
+
+  Coisas ruins que você deve evitar dizer:
+
+    - "Nós fizemos desta forma no AIX/ptx/Solaris, portanto deve ser bom..."
+    - "Eu faço isso há 20 anos, então..."
+    - "Isto é necessário para minha empresa ganhar dinheiro."
+    - "Isto é para nossa linha de produtos Enterprise."
+    - "Aqui está meu documento de design de 1000 páginas que descreve minha ideia."
+    - "Estou trabalhando nisso há 6 meses..."
+    - "Aqui está um patch de 5000 linhas que..."
+    - "Eu reescrevi toda a bagunça atual, e aqui está..."
+    - "Eu tenho um prazo (deadline), e este patch precisa ser aplicado agora."
+
+Outra forma em que a comunidade do kernel difere da maioria dos ambientes
+tradicionais de engenharia de software é a natureza anônima da interação.
+Um benefício de usar e-mail e IRC como as principais formas de comunicação
+é a ausência de discriminação baseada em gênero ou raça. O ambiente de
+trabalho do kernel Linux aceita mulheres e minorias porque tudo o que você
+é, é um endereço de e-mail. O aspecto internacional também ajuda a nivelar
+o campo de jogo porque você não pode adivinhar o gênero com base no nome
+de uma pessoa. Um homem pode se chamar Andrea e uma mulher pode se chamar
+Pat. A maioria das mulheres que trabalharam no kernel Linux e expressaram
+uma opinião tiveram experiências positivas.
+
+A barreira do idioma pode causar problemas para algumas pessoas que não
+se sentem confortáveis com o inglês. Um bom domínio do idioma pode ser
+necessário para transmitir ideias adequadamente nas listas de discussão,
+por isso recomenda-se que você verifique seus e-mails para garantir que
+façam sentido em inglês antes de enviá-los.
+
+
+Divida suas alterações
+----------------------
+
+A comunidade do kernel Linux não aceita de bom grado grandes blocos de
+código jogados de uma só vez. As mudanças precisam ser devidamente
+introduzidas, discutidas e divididas em porções minúsculas e individuais.
+Isso é quase o exato oposto do que as empresas costumam fazer. Sua proposta
+também deve ser introduzida muito cedo no processo de desenvolvimento, para
+que você possa receber feedback sobre o que está fazendo. Isso também permite
+que a comunidade sinta que você está trabalhando com eles, e não simplesmente
+usando-os como um depósito para sua funcionalidade. No entanto, não envie
+50 e-mails de uma só vez para uma lista de discussão; sua série de patches
+deve ser menor que isso quase sempre.
+
+As razões para dividir as coisas são as seguintes:
+
+1) Patches pequenos aumentam a probabilidade de serem aplicados, pois não
+   exigem muito tempo ou esforço para verificar sua correção. Um patch de
+   5 linhas pode ser aplicado por um mantenedor com apenas um olhar rápido.
+   No entanto, um patch de 500 linhas pode levar horas para ser revisado
+   (o tempo que leva é exponencialmente proporcional ao tamanho do patch,
+   ou algo assim).
+
+   Patches pequenos também tornam muito fácil a depuração (debug) quando
+   algo dá errado. É muito mais fácil reverter patches um por um do que
+   dissecar um patch muito grande após ele ter sido aplicado (e quebrado algo).
+
+2) É importante não apenas enviar patches pequenos, mas também reescrever
+   e simplificar (ou simplesmente reordenar) os patches antes de submetê-los.
+
+Aqui está uma analogia do desenvolvedor do kernel Al Viro:
+
+    *"Pense em um professor corrigindo o dever de casa de um aluno de
+    matemática. O professor não quer ver as tentativas e erros do aluno
+    antes de chegar à solução. Ele quer ver a resposta mais limpa e
+    elegante. Um bom aluno sabe disso e nunca enviaria seu trabalho
+    intermediário antes da solução final.*
+
+    *O mesmo vale para o desenvolvimento do kernel. Os mantenedores e
+    revisores não querem ver o processo de pensamento por trás da solução
+    do problema que se está resolvendo. Eles querem ver uma solução
+    simples e elegante."*
+
+Pode ser desafiador manter o equilíbrio entre apresentar uma solução
+elegante e trabalhar em conjunto com a comunidade discutindo seu trabalho
+inacabado. Portanto, é bom entrar no processo cedo para obter feedback e
+melhorar seu trabalho, mas também manter suas alterações em pequenos blocos
+que possam ser aceitos, mesmo quando sua tarefa completa ainda não esteja
+pronta para inclusão.
+
+Também entenda que não é aceitável enviar patches para inclusão que estejam
+inacabados e que serão "consertados mais tarde".
+
+
+Justifique sua alteração
+------------------------
+
+Além de dividir seus patches, é muito importante que você deixe a comunidade
+Linux saber por que eles deveriam adicionar essa mudança. Novas
+funcionalidades devem ser justificadas como necessárias e úteis.
+
+
+Documente sua alteração
+-----------------------
+
+Ao enviar seus patches, preste atenção especial ao que você diz no texto
+do seu e-mail. Essas informações se tornarão as informações do ChangeLog
+para o patch e serão preservadas para que todos vejam para sempre. Elas
+devem descrever o patch completamente, contendo:
+
+  - por que a mudança é necessária
+  - a abordagem geral de design no patch
+  - detalhes de implementação
+  - resultados de testes
+
+Para mais detalhes sobre como tudo isso deve ser, por favor, veja a seção
+ChangeLog do documento:
+
+  "O Patch Perfeito"
+      https://www.ozlabs.org/~akpm/stuff/tpp.txt
+
+Todas essas coisas às vezes são muito difíceis de fazer. Pode levar anos
+para aperfeiçoar essas práticas (se é que é possível). É um processo
+contínuo de melhoria que exige muita paciência e determinação. Mas não
+desista, é possível. Muitos fizeram isso antes, e cada um teve que começar
+exatamente onde você está agora.
+
+----------
+
+Agradecimentos a Paolo Ciarrocchi, que permitiu que a seção "Processo de
+Desenvolvimento" (https://lwn.net/Articles/94386/) fosse baseada em um
+texto que ele escreveu, e a Randy Dunlap e Gerrit Huizenga por parte da
+lista de coisas que você deve ou não dizer. Também agradecemos a Pat Mochel,
+Hanna Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara,
+Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl,
+Adrian Bunk, Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano,
+Michael Kerrisk e Alex Shepard por suas revisões, comentários e contribuições.
+Sem a ajuda deles, este documento não teria sido possível.
+
+Mantenedor: Greg Kroah-Hartman <greg@kroah.com>

linux-7.2.3/Documentation/translations/pt_BR/process/kernel-docs.rst

@@ -0,0 +1,373 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Índice de Documentação Adicional do Kernel
+==========================================
+
+A necessidade de um documento como este tornou-se evidente na lista de discussão
+linux-kernel, uma vez que as mesmas perguntas, solicitando referências de
+informações, apareciam repetidamente.
+
+Felizmente, à medida que cada vez mais pessoas chegam ao GNU/Linux, mais pessoas
+se interessam pelo Kernel. No entanto, ler o código-fonte nem sempre é o
+suficiente. É fácil entender o código, mas perder os conceitos, a filosofia
+e as decisões de design por trás dele.
+
+Infelizmente, não há muitos documentos disponíveis para iniciantes começarem.
+E, mesmo quando existem, não havia um local "bem conhecido" que os centralizasse.
+Estas linhas tentam suprir essa falta.
+
+POR FAVOR, se você conhece algum artigo não listado aqui ou se escrever um novo
+documento, inclua uma referência a ele aqui, seguindo o processo de envio de
+patches do kernel. Quaisquer correções, ideias ou comentários também são
+bem-vindos.
+
+Todos os documentos estão catalogados com os seguintes campos: o "Título" do
+documento, o(s) "Autor(es)", a "URL" onde podem ser encontrados, algumas
+"Palavras-chave" úteis para pesquisar tópicos específicos e uma breve
+"Descrição" do documento.
+
+.. note::
+
+   Os documentos em cada seção deste documento estão ordenados por sua data de
+   publicação, do mais recente para o mais antigo. O(s) mantenedor(es) deve(m)
+   remover periodicamente recursos à medida que se tornem obsoletos ou
+   desatualizados; com exceção de livros fundamentais.
+
+Documentação na árvore do Kernel
+--------------------------------
+
+Os manuais Sphinx devem ser compilados com ``make {htmldocs | pdfdocs | epubdocs}``.
+
+    * Nome: **linux/Documentation**
+
+      :Autor: Muitos.
+      :Localização: Documentation/
+      :Palavras-chave: arquivos de texto, Sphinx.
+      :Descrição: Documentação que acompanha o código-fonte do kernel,
+        dentro do diretório Documentation. Algumas páginas deste documento
+        (incluindo este próprio documento) foram movidas para lá e podem
+        estar mais atualizadas do que a versão web.
+
+Documentação on-line
+--------------------
+
+    * Título: **Linux Kernel Mailing List Glossary**
+
+      :Autor: diversos
+      :URL: https://kernelnewbies.org/KernelGlossary
+      :Data: versão contínua (rolling)
+      :Palavras-chave: glossário, termos, linux-kernel.
+      :Descrição: Da introdução: "Este glossário destina-se a ser uma breve
+        descrição de algumas das siglas e termos que você poderá ouvir durante
+        as discussões sobre o kernel Linux".
+
+    * Título: **The Linux Kernel Module Programming Guide**
+
+      :Autor: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram,
+        Jim Huang.
+      :URL: https://sysprog21.github.io/lkmpg/
+      :Data: 2021
+      :Palavras-chave: módulos, livro GPL, /proc, ioctls, chamadas de sistema,
+        manipuladores de interrupção.
+      :Descrição: Um excelente livro sob licença GPL sobre o tópico de
+        programação de módulos. Repleto de exemplos. Atualmente, a nova versão
+        está sendo mantida ativamente em https://github.com/sysprog21/lkmpg.
+
+Livros Publicados
+-----------------
+
+    * Title: **The Linux Memory Manager**
+
+      :Autor: Lorenzo Stoakes
+      :Editora: No Starch Press
+      :Data: Fevereiro 2025
+      :Páginas: 1300
+      :ISBN: 978-1718504462
+      :Notas: Gerenciamento de memória. Rascunho completo disponível como acesso
+        antecipado para ré-venda, lançamento completo agendado para o
+        outono de 2025. Veja https://nostarch.com/linux-memory-manager
+        para mais informações.
+
+    * Title: **Practical Linux System Administration: A Guide to Installation, Configuration, and Management, 1st Edition**
+
+      :Autor: Kenneth Hess
+      :Editora: O'Reilly Media
+      :Data: Maio, 2023
+      :Páginas: 246
+      :ISBN: 978-1098109035
+      :Notas: Administração de sistemas
+
+    * Title: **Linux Kernel Debugging: Leverage proven tools and advanced techniques to effectively debug Linux kernels and kernel modules**
+
+      :Autor: Kaiwan N Billimoria
+      :Editora: Packt Publishing Ltd
+      :Data: Agosto, 2022
+      :Páginas: 638
+      :ISBN: 978-1801075039
+      :Notas: Livro sobre depuração (debugging)
+
+    * Title: **Linux Kernel Programming: A Comprehensive Guide to Kernel Internals, Writing Kernel Modules, and Kernel Synchronization**
+
+      :Autor: Kaiwan N Billimoria
+      :Editora: Packt Publishing Ltd
+      :Data: Março, 2021 (Segunda edição publicada em 2024)
+      :Páginas: 754
+      :ISBN: 978-1789953435 (O ISBN da segunda edição é 978-1803232225)
+
+    * Title: **Linux Kernel Programming Part 2 - Char Device Drivers and Kernel Synchronization: Create user-kernel interfaces, work with peripheral I/O, and handle hardware interrupts**
+
+      :Autor: Kaiwan N Billimoria
+      :Editora: Packt Publishing Ltd
+      :Data: Março, 2021
+      :Páginas: 452
+      :ISBN: 978-1801079518
+
+    * Title: **Linux System Programming: Talking Directly to the Kernel and C Library**
+
+      :Autor: Robert Love
+      :Editora: O'Reilly Media
+      :Data: Junho, 2013
+      :Páginas: 456
+      :ISBN: 978-1449339531
+      :Notas: Livro fundamental
+
+    * Título: **Linux Kernel Development, 3rd Edition**
+
+      :Autor: Robert Love
+      :Editora: Addison-Wesley
+      :Data: Julho de 2010
+      :Páginas: 440
+      :ISBN: 978-0672329463
+      :Notas: Livro fundamental
+
+    * Título: **Linux Device Drivers, 3rd Edition**
+
+      :Autores: Jonathan Corbet, Alessandro Rubini e Greg Kroah-Hartman
+      :Editora: O'Reilly & Associates
+      :Data: 2005
+      :Páginas: 636
+      :ISBN: 0-596-00590-3
+      :Notas: Livro fundamental. Mais informações em
+        http://www.oreilly.com/catalog/linuxdrive3/
+        Formato PDF, URL: https://lwn.net/Kernel/LDD3/
+
+    * Título: **The Design of the UNIX Operating System**
+
+      :Autor: Maurice J. Bach
+      :Editora: Prentice Hall
+      :Data: 1986
+      :Páginas: 471
+      :ISBN: 0-13-201757-1
+      :Notas: Livro fundamental
+
+Diversos
+--------
+
+    * Nome: **Cross-Referencing Linux**
+
+      :URL: https://elixir.bootlin.com/
+      :Palavras-chave: Navegação em código-fonte.
+      :Descrição: Outro navegador web para o código-fonte do kernel Linux.
+        Possui muitas referências cruzadas para variáveis e funções. Você pode
+        ver onde elas são definidas e onde são utilizadas.
+
+    * Nome: **Linux Weekly News**
+
+      :URL: https://lwn.net
+      :Palavras-chave: últimas notícias do kernel.
+      :Descrição: O título diz tudo. Há uma seção fixa sobre o kernel que
+        resume o trabalho dos desenvolvedores, correções de bugs, novos recursos
+        e versões produzidas durante a semana.
+
+    * Nome: **The home page of Linux-MM**
+
+      :Autor: A equipe Linux-MM.
+      :URL: https://linux-mm.org/
+      :Palavras-chave: gerenciamento de memória, Linux-MM, mm patches, TODO,
+        docs, mailing list.
+      :Descrição: Site dedicado ao desenvolvimento do Gerenciamento de Memória
+        do Linux. Patches relacionados à memória, HOWTOs, links, desenvolvedores
+        mm... Não perca se você estiver interessado no desenvolvimento do
+        gerenciamento de memória!
+
+    * Nome: **Kernel Newbies IRC Channel and Website**
+
+      :URL: https://www.kernelnewbies.org
+      :Palavras-chave: IRC, novatos, canal, tirar dúvidas.
+      :Descrição: #kernelnewbies em irc.oftc.net.
+        O canal #kernelnewbies é uma rede de IRC dedicada ao hacker de kernel
+        "novato" (newbie). O público consiste principalmente de pessoas que estão
+        aprendendo sobre o kernel, trabalhando em projetos do kernel ou hackers
+        profissionais que desejam ajudar pessoas menos experientes.
+        O #kernelnewbies está na rede de IRC OFTC.
+        Tente acessar irc.oftc.net como seu servidor e então digite /join #kernelnewbies.
+        O site kernelnewbies também hospeda artigos, documentos, FAQs...
+
+    * Nome: **linux-kernel mailing list archives and search engines**
+
+      :URL: https://subspace.kernel.org
+      :URL: https://lore.kernel.org
+      :Palavras-chave: linux-kernel, arquivos, busca.
+      :Descrição: Alguns dos arquivadores da lista de discussão linux-kernel.
+        Se você conhece algum outro (ou um melhor), por favor, me avise.
+
+    * Nome: **The Linux Foundation YouTube channel**
+
+      :URL: https://www.youtube.com/user/thelinuxfoundation
+      :Palavras-chave: linux, vídeos, linux-foundation, youtube.
+      :Descrição: A Linux Foundation faz o upload de gravações de vídeo de seus
+        eventos colaborativos, conferências de Linux (incluindo a LinuxCon) e
+        outras pesquisas originais e conteúdos relacionados ao Linux e ao
+        desenvolvimento de software.
+
+Rust
+----
+
+    * Título: **Rust for Linux**
+
+      :Autor: diversos
+      :URL: https://rust-for-linux.com/
+      :Data: versão contínua (rolling)
+      :Palavras-chave: glossário, termos, linux-kernel, rust.
+      :Descrição Do site: "Rust for Linux é o projeto que adiciona suporte à
+        linguagem Rust ao kernel Linux. Este site pretende ser um hub de links,
+        documentação e recursos relacionados ao projeto".
+
+    * Título: **Learn Rust the Dangerous Way**
+
+      :Autor: Cliff L. Biffle
+      :URL: https://cliffle.com/p/dangerust/
+      :Data: Acessado em 11 de setembro de 2024
+      :Palavras-chave: rust, blog.
+      :Descrição: Do site: "LRtDW é uma série de artigos que coloca os recursos
+        do Rust em contexto para programadores C de baixo nível que talvez não
+        tenham uma formação formal em Ciência da Computação, o tipo de pessoa
+        que trabalha com firmware, engines de jogos, kernels de SO e afins.
+        Basicamente, pessoas como eu.". O site ilustra conversões de linha por
+        linha de C para Rust.
+
+    * Título: **The Rust Book**
+
+      :Autor: Steve Klabnik e Carol Nichols, com contribuições da comunidade Rust
+      :URL: https://doc.rust-lang.org/book/
+      :Data: Acessado em 11 de setembro de 2024
+      :Palavras-chave: rust, livro.
+      :Descrição: Do site: "Este livro abraça totalmente o potencial do Rust para
+        capacitar seus usuários. É um texto amigável e acessível destinado a
+        ajudá-lo a elevar não apenas seu conhecimento de Rust, mas também seu
+        alcance e confiança como programador em geral. Então mergulhe de cabeça,
+        prepare-se para aprender e bem-vindo à comunidade Rust!".
+
+    * Título: **Rust for the Polyglot Programmer**
+
+      :Autor: Ian Jackson
+      :URL: https://www.chiark.greenend.org.uk/~ianmdlvl/rust-polyglot/index.html
+      :Data: Dezembro de 2022
+      :Palavras-chave: rust, blog, tooling.
+      :Descrição: Do site: "Existem muitos guias e introduções ao Rust. Este é
+        algo diferente: destina-se ao programador experiente que já conhece
+        muitas outras linguagens de programação. Tento ser abrangente o suficiente
+        para servir de ponto de partida para qualquer área do Rust, mas evito
+        entrar em detalhes excessivos, exceto onde as coisas não são como você
+        poderia esperar. Além disso, este guia não é inteiramente isento de
+        opiniões, incluindo recomendações de bibliotecas (crates), ferramentas, etc.".
+
+    * Título: **Fasterthanli.me**
+
+      :Autor: Amos Wenger
+      :URL: https://fasterthanli.me/
+      :Data: Acessado em 11 de setembro de 2024
+      :Palavras-chave: rust, blog, notícias.
+      :Descrição: Do site: "Eu crio artigos e vídeos sobre como os computadores
+        funcionam. Meu conteúdo é de formato longo, didático e exploratório
+        e frequentemente uma desculpa para ensinar Rust!".
+
+    * Título: **Comprehensive Rust**
+
+      :Autor: Equipe Android do Google
+      :URL: https://google.github.io/comprehensive-rust/
+      :Data: Acessado em 13 de setembro de 2024
+      :Palavras-chave: rust, blog.
+      :Descrição: Do site: "O curso cobre todo o espectro do Rust, desde a
+        sintaxe básica até tópicos avançados como genéricos e tratamento de erros".
+
+    * Título: **The Embedded Rust Book**
+
+      :Autor: Múltiplos colaboradores, principalmente Jorge Aparicio
+      :URL: https://docs.rust-embedded.org/book/
+      :Data: Acessado em 13 de setembro de 2024
+      :Palavras-chave: rust, blog.
+      :Descrição: Do site: "Um livro introdutório sobre o uso da linguagem de
+        programação Rust em sistemas embarcados 'Bare Metal', como microcontroladores".
+
+    * Título: **Experiment: Improving the Rust Book**
+
+      :Autor: Cognitive Engineering Lab na Brown University
+      :URL: https://rust-book.cs.brown.edu/
+      :Data: Acessado em 22 de setembro de 2024
+      :Palavras-chave: rust, blog.
+      :Descrição: Do site: "O objetivo deste experimento é avaliar e melhorar o
+        conteúdo do Rust Book para ajudar as pessoas a aprenderem Rust de forma
+        mais eficaz".
+
+    * Título: **New Rustacean** (podcast)
+
+      :Autor: Chris Krycho
+      :URL: https://newrustacean.com/
+      :Data: Acessado em 22 de setembro de 2024
+      :Palavras-chave: rust, podcast.
+      :Descrição: Do site: "Este é um podcast sobre aprender a linguagem de
+        programação Rust do zero! Além desta página inicial elegante, todo o
+        conteúdo do site é construído com as próprias ferramentas de documentação
+        do Rust".
+
+    * Título: **Opsem-team** (repositório)
+
+      :Autor: Equipe de semântica operacional (Operational semantics team)
+      :URL: https://github.com/rust-lang/opsem-team/tree/main
+      :Data: Acessado em 22 de setembro de 2024
+      :Palavras-chave: rust, repositório.
+      :Descrição: Do README: "A equipe opsem é a sucessora do grupo de trabalho
+        unsafe-code-guidelines e é responsável por responder a muitas das perguntas
+        difíceis sobre a semântica do Rust inseguro (unsafe Rust)".
+
+    * Título: **You Can't Spell Trust Without Rust**
+
+      :Autor: Alexis Beingessner
+      :URL: https://repository.library.carleton.ca/downloads/1j92g820w?locale=en
+      :Data: 2015
+      :Palavras-chave: rust, mestrado, tese.
+      :Descrição: Esta tese foca no sistema de propriedade (ownership) do Rust,
+        que garante a segurança de memória ao controlar a manipulação de dados e
+        o tempo de vida, enquanto também destaca suas limitações e o compara a
+        sistemas semelhantes no Cyclone e C++.
+
+    * Nome: **Apresentações de Rust no Linux Plumbers (LPC) 2024**
+
+      :Título: Rust microconference
+      :URL: https://lpc.events/event/18/sessions/186/#20240918
+      :Título: Rust for Linux
+      :URL: https://lpc.events/event/18/contributions/1912/
+      :Título: Journey of a C kernel engineer starting a Rust driver project
+      :URL: https://lpc.events/event/18/contributions/1911/
+      :Título: Crafting a Linux kernel scheduler that runs in user-space using Rust
+      :URL: https://lpc.events/event/18/contributions/1723/
+      :Título: openHCL: A Linux and Rust based paravisor
+      :URL: https://lpc.events/event/18/contributions/1956/
+      :Palavras-chave: rust, lpc, apresentações.
+      :Descrição: Uma série de palestras do LPC relacionadas ao Rust.
+
+    * Nome: **The Rustacean Station Podcast**
+
+      :URL: https://rustacean-station.org/
+      :Palavras-chave: rust, podcasts.
+      :Descrição: Um projeto comunitário para a criação de conteúdo em podcast
+        sobre a linguagem de programação Rust.
+
+-------
+
+Este documento foi originalmente baseado em:
+
+https://www.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html
+
+e escrito por Juan-Mariano de Goyeneche.

linux-7.2.3/Documentation/translations/pt_BR/process/license-rules.rst

@@ -0,0 +1,483 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Regras de licenciamento do kernel Linux
+=======================================
+
+O Kernel Linux é fornecido apenas sob os termos da licença GNU General Public
+License versão 2 (GPL-2.0), conforme estabelecido em LICENSES/preferred/GPL-2.0,
+com uma exceção explícita para syscalls descrita em
+LICENSES/exceptions/Linux-syscall-note, conforme descrito no arquivo COPYING.
+
+Este arquivo de documentação fornece uma descrição de como cada arquivo-fonte
+deve ser anotado para tornar sua licença clara e inequívoca. Ele não substitui
+a licença do Kernel.
+
+A licença descrita no arquivo COPYING aplica-se ao código-fonte do kernel como
+um todo, embora arquivos-fonte individuais possam ter uma licença diferente, a
+qual deve ser obrigatoriamente compatível com a GPL-2.0::
+
+    GPL-1.0+  :  GNU General Public License v1.0 ou posterior
+    GPL-2.0+  :  GNU General Public License v2.0 ou posterior
+    LGPL-2.0  :  GNU Library General Public License v2 apenas
+    LGPL-2.0+ :  GNU Library General Public License v2 ou posterior
+    LGPL-2.1  :  GNU Lesser General Public License v2.1 apenas
+    LGPL-2.1+ :  GNU Lesser General Public License v2.1 ou posterior
+
+Além disso, arquivos individuais podem ser fornecidos sob uma licença dupla
+(dual license), por exemplo, uma das variantes GPL compatíveis e,
+alternativamente, sob uma licença permissiva como BSD, MIT, etc.
+
+Os arquivos de cabeçalho da API do espaço do usuário (UAPI), que descrevem a
+interface dos programas do espaço do usuário com o kernel, são um caso especial.
+De acordo com a nota no arquivo COPYING do kernel, a interface de syscall é um
+limite claro, que não estende os requisitos da GPL a qualquer software que a
+utilize para se comunicar com o kernel. Como os cabeçalhos UAPI devem ser
+passíveis de inclusão em quaisquer arquivos-fonte que criem um executável
+executado no kernel Linux, a exceção deve ser documentada por uma expressão de
+licença especial.
+
+A forma comum de expressar a licença de um arquivo-fonte é adicionar o texto
+padrão (boilerplate) correspondente no comentário inicial do arquivo. Devido a
+variações de formatação, erros de digitação, etc., esses "textos padrão" são
+difíceis de validar por ferramentas usadas no contexto de conformidade de
+licença.
+
+Uma alternativa aos textos padrão é o uso de identificadores de licença
+Software Package Data Exchange (SPDX) em cada arquivo-fonte. Os identificadores
+de licença SPDX são abreviações precisas e analisáveis por máquina para a
+licença sob a qual o conteúdo do arquivo é contribuído. Os identificadores de
+licença SPDX são gerenciados pelo Grupo de Trabalho SPDX na Linux Foundation e
+foram acordados por parceiros em toda a indústria, fornecedores de ferramentas
+e equipes jurídicas. Para mais informações, consulte https://spdx.org/
+
+O kernel Linux exige o identificador SPDX preciso em todos os arquivos-fonte.
+Os identificadores válidos usados no kernel são explicados na seção
+`Identificadores de Licença`_ e foram obtidos da lista de licenças
+oficial do  SPDX em https://spdx.org/licenses/ junto com os textos das licenças.
+
+Sintaxe do identificador de licença
+-----------------------------------
+
+1. Posicionamento:
+
+   O identificador de licença SPDX em arquivos do kernel deve ser adicionado na
+   primeira linha possível do arquivo que possa conter um comentário. Para a
+   maioria dos arquivos, esta é a primeira linha, exceto para scripts que
+   requerem o '#!CAMINHO_PARA_INTERPRETADOR' na primeira linha. Para esses
+   scripts, o identificador de licença SPDX deve ser colocado na segunda linha.
+
+   A linha do identificador de licença pode então ser seguida por uma ou
+   múltiplas linhas de SPDX-FileCopyrightText, se desejado.
+
+2. Estilo:
+
+   O identificador de licença SPDX é adicionado na forma de um comentário. O
+   estilo do comentário depende do tipo de arquivo::
+
+      Fonte C:    // SPDX-License-Identifier: <Expressão de Licença SPDX>
+      Cabeçalho C:/* SPDX-License-Identifier: <Expressão de Licença SPDX> */
+      ASM:        /* SPDX-License-Identifier: <Expressão de Licença SPDX> */
+      scripts:    # SPDX-License-Identifier: <Expressão de Licença SPDX>
+      .rst:       .. SPDX-License-Identifier: <Expressão de Licença SPDX>
+      .dts{i}:    // SPDX-License-Identifier: <Expressão de Licença SPDX>
+
+   Se uma ferramenta específica não conseguir lidar com o estilo de comentário
+   padrão, então deve ser utilizado o mecanismo de comentário apropriado que a
+   ferramenta aceite. Este é o motivo para ter o comentário no estilo ``/* */``
+   em arquivos de cabeçalho C. Foi observada uma quebra de build com arquivos
+   .lds gerados, onde o 'ld' falhou ao analisar o comentário C++. Isso já foi
+   corrigido, mas ainda existem ferramentas de assembler mais antigas que não
+   conseguem lidar com comentários no estilo C++.
+
+3. Sintaxe:
+
+   Uma <Expressão de Licença SPDX> pode ser um identificador SPDX simplificado
+   encontrado na Lista de Licenças SPDX, ou a combinação de dois desses
+   identificadores separados por "WITH", caso uma exceção de licença se aplique.
+   Quando múltiplas licenças são aplicáveis, a expressão utiliza as palavras-chave
+   "AND" ou "OR" para separar as sub-expressões, que devem ser delimitadas
+   por parênteses "(", ")".
+
+   Para licenças como [L]GPL, utiliza-se o sufixo "+" para indicar a opção
+   'ou posterior'::
+
+      // SPDX-License-Identifier: GPL-2.0+
+      // SPDX-License-Identifier: LGPL-2.1+
+
+   O termo "WITH" deve ser usado sempre que houver um modificador necessário
+   para a licença. Por exemplo, os arquivos UAPI do kernel Linux utilizam a
+   expressão::
+
+      // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+      // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
+
+   Outros exemplos de uso da cláusula "WITH" para exceções no kernel são::
+
+      // SPDX-License-Identifier: GPL-2.0 WITH mif-exception
+      // SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0
+
+   As exceções só podem ser aplicadas a identificadores de licença específicos.
+   Os identificadores válidos estão listados nas tags do arquivo de texto de
+   cada exceção. Para detalhes, veja o ponto `Exceções`_ no capítulo
+   `Identificadores de Licença`_.
+
+   O termo "OR" deve ser usado se o arquivo possuir licenciamento duplo (dual
+   licensed) e apenas uma das licenças puder ser selecionada. Por exemplo,
+   alguns arquivos dtsi estão disponíveis sob licença dupla::
+
+      // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+
+   Exemplos de expressões para arquivos com licenciamento duplo no kernel::
+
+      // SPDX-License-Identifier: GPL-2.0 OR MIT
+      // SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
+      // SPDX-License-Identifier: GPL-2.0 OR Apache-2.0
+      // SPDX-License-Identifier: GPL-2.0 OR MPL-1.1
+      // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT
+      // SPDX-License-Identifier: GPL-1.0+ OR BSD-3-Clause OR OpenSSL
+
+   O termo "AND" deve ser usado se o arquivo possuir múltiplas licenças cujos
+   termos devem ser aplicados simultaneamente. Por exemplo, se um código herdado
+   de outro projeto foi incorporado ao kernel, mas os termos da licença original
+   ainda precisam ser respeitados::
+
+      // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT
+
+   Outro exemplo onde ambos os conjuntos de termos devem ser cumpridos é::
+
+      // SPDX-License-Identifier: GPL-1.0+ AND LGPL-2.1+
+
+Identificadores de Licença
+--------------------------
+
+As licenças atualmente em uso, bem como as licenças para código adicionado ao
+kernel, podem ser divididas em:
+
+4. _`Licenças preferenciais`:
+
+   Sempre que possível, estas licenças devem ser utilizadas, pois são conhecidas
+   por serem totalmente compatíveis e amplamente usadas. Estas licenças estão
+   disponíveis no diretório::
+
+      LICENSES/preferred/
+
+   na árvore de diretórios do código-fonte do kernel.
+
+   Os arquivos neste diretório contêm o texto completo da licença e as
+   `Metatags`_. Os nomes dos arquivos são idênticos ao identificador de licença
+   SPDX que deve ser utilizado para a licença nos arquivos-fonte.
+
+   Exemplos::
+
+      LICENSES/preferred/GPL-2.0
+
+   Contém o texto da licença GPL versão 2 e as metatags obrigatórias::
+
+      LICENSES/preferred/MIT
+
+   Contém o texto da licença MIT e as metatags obrigatórias.
+
+   _`Metatags`:
+
+   As seguintes metatags devem estar presentes em um arquivo de licença:
+
+   - Valid-License-Identifier:
+
+     Uma ou mais linhas que declaram quais Identificadores de Licença são válidos
+     dentro do projeto para referenciar este texto de licença específico.
+     Geralmente, trata-se de um único identificador válido, mas, por exemplo,
+     para licenças com as opções 'ou posterior' (or later), dois identificadores
+     são válidos.
+
+   - SPDX-URL:
+
+     A URL da página SPDX que contém informações adicionais relacionadas à licença.
+
+   - Usage-Guidance:
+
+     Texto livre para conselhos de uso. O texto deve incluir exemplos corretos
+     para os identificadores de licença SPDX, conforme eles devem ser colocados
+     nos arquivos-fonte de acordo com as diretrizes de
+     `Sintaxe do identificador de licença`_.
+
+   - License-Text:
+
+     Todo o texto após esta tag é tratado como o texto original da licença.
+
+   Exemplos de formato de arquivo::
+
+      Valid-License-Identifier: GPL-2.0
+      Valid-License-Identifier: GPL-2.0+
+      SPDX-URL: https://spdx.org/licenses/GPL-2.0.html
+      Usage-Guide:
+        Para usar esta licença no código-fonte, coloque um dos seguintes pares
+        SPDX tag/valor em um comentário, de acordo com as diretrizes de
+        posicionamento na documentação das regras de licenciamento.
+        Para 'GNU General Public License (GPL) version 2 only', use:
+          SPDX-License-Identifier: GPL-2.0
+        Para 'GNU General Public License (GPL) version 2 or any later version', use:
+          SPDX-License-Identifier: GPL-2.0+
+      License-Text:
+        Texto completo da licença
+
+   ::
+
+      Valid-License-Identifier: MIT
+      SPDX-URL: https://spdx.org/licenses/MIT.html
+      Usage-Guide:
+        Para usar esta licença no código-fonte, coloque o seguinte par SPDX
+        tag/valor em um comentário, de acordo com as diretrizes de
+        posicionamento na documentação das regras de licenciamento.
+          SPDX-License-Identifier: MIT
+      License-Text:
+        Texto completo da licença
+
+5. Licenças obsoletas:
+
+   Estas licenças devem ser utilizadas apenas para código já existente ou para
+   a importação de código de outros projetos. Estas licenças estão disponíveis
+   no diretório::
+
+      LICENSES/deprecated/
+
+   na árvore de fontes do kernel.
+
+   Os arquivos neste diretório contêm o texto completo da licença e as
+   `Metatags`_. Os nomes dos arquivos são idênticos ao identificador de
+   licença SPDX que deve ser utilizado para a licença nos arquivos fonte.
+
+   Exemplos::
+
+      LICENSES/deprecated/ISC
+
+   Contém o texto da licença *Internet Systems Consortium* e as metatags
+   necessárias::
+
+      LICENSES/deprecated/GPL-1.0
+
+   Contém o texto da licença GPL versão 1 e as metatags necessárias.
+
+   Metatags:
+
+   Os requisitos de metatags para "outras" licenças são idênticos aos
+   requisitos das `Licenças preferenciais`_.
+
+   Exemplo de formato de arquivo::
+
+      Valid-License-Identifier: ISC
+      SPDX-URL: https://spdx.org/licenses/ISC.html
+      Usage-Guide:
+        O uso desta licença no kernel para novos códigos é desencorajado
+        e deve ser utilizada exclusivamente para importar código de um
+        projeto já existente.
+        Para usar esta licença no código-fonte, coloque o seguinte par
+        tag/valor SPDX em um comentário, seguindo as diretrizes de
+        posicionamento na documentação das regras de licenciamento.
+          SPDX-License-Identifier: ISC
+      License-Text:
+        Texto completo da licença
+
+6. Apenas Licenciamento Duplo
+
+   Estas licenças devem ser usadas apenas para o licenciamento duplo de código
+   com outra licença, além de uma licença preferencial. Estas licenças estão
+   disponíveis no diretório::
+
+      LICENSES/dual/
+
+   No código-fonte do kernel.
+
+   Os arquivos neste diretório contêm o texto completo da licença e as
+   `Metatags`_. Os nomes dos arquivos são idênticos ao identificador de licença
+   SPDX que deve ser usado para a licença nos arquivos fonte.
+
+   Exemplos::
+
+      LICENSES/dual/MPL-1.1
+
+   Contém o texto da licença Mozilla Public License versão 1.1 e as metatags
+   necessárias::
+
+      LICENSES/dual/Apache-2.0
+
+   Contém o texto da licença Apache License versão 2.0 e as metatags
+   necessárias.
+
+   Metatags:
+
+   Os requisitos de metatags para 'outras' licenças são idênticos aos
+   requisitos das `Licenças preferenciais`_.
+
+   Exemplo de formato de arquivo::
+
+      Valid-License-Identifier: MPL-1.1
+      SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
+      Usage-Guide:
+        NÃO use. A licença MPL-1.1 não é compatível com a GPL2. Ela só pode ser
+        usada para arquivos com licenciamento duplo onde a outra licença seja
+        compatível com a GPL2.
+        Se você acabar utilizando-a, ela DEVE ser usada em conjunto com uma
+        licença compatível com a GPL2 utilizando "OR".
+        Para usar a Mozilla Public License versão 1.1, coloque o seguinte par
+        tag/valor SPDX em um comentário, de acordo com as diretrizes de
+        posicionamento na documentação das regras de licenciamento:
+      SPDX-License-Identifier: MPL-1.1
+      License-Text:
+        Texto completo da licença
+
+|
+
+7. _`Exceções`:
+
+Algumas licenças podem ser alteradas com exceções que concedem certos direitos
+   que a licença original não concede. Estas exceções estão disponíveis no
+   diretório::
+
+      LICENSES/exceptions/
+
+   no código-fonte do kernel. Os arquivos neste diretório contêm o texto completo
+   da exceção e as `Metatags de Exceção`_ necessárias.
+
+   Exemplos::
+
+      LICENSES/exceptions/Linux-syscall-note
+
+   Contém a exceção de syscall do Linux, conforme documentado no arquivo COPYING
+   do kernel Linux, que é usada para arquivos de cabeçalho UAPI.
+   ex: /\* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note \*/::
+
+      LICENSES/exceptions/GCC-exception-2.0
+
+   Contém a 'exceção de vinculação' do GCC, que permite
+   vincular qualquer binário, independente de sua licença, à versão compilada
+   de um arquivo marcado com esta exceção. Isso é necessário para criar
+   executáveis funcionais a partir de código-fonte que não seja compatível
+   com a GPL.
+
+   _`Metatags de Exceção`:
+
+   As seguintes meta tags devem estar disponíveis em um arquivo de exceção:
+
+   - SPDX-Exception-Identifier:
+
+     Um identificador de exceção que pode ser usado com identificadores de
+     licença SPDX.
+
+   - SPDX-URL:
+
+     A URL da página SPDX que contém informações adicionais relacionadas
+     à exceção.
+
+   - SPDX-Licenses:
+
+     Uma lista separada por vírgulas de identificadores de licença SPDX para os
+     quais a exceção pode ser usada.
+
+   - Usage-Guidance:
+
+     Texto de formato livre para conselhos de uso. O texto deve ser seguido por
+     exemplos corretos para os identificadores de licença SPDX, conforme devem
+     ser colocados nos arquivos fonte de acordo com as diretrizes de
+     `Sintaxe do identificador de licença`_.
+
+   - Exception-Text:
+
+     Todo o texto após esta tag é tratado como o texto original da exceção.
+
+   Exemplos de formato de arquivo::
+
+      SPDX-Exception-Identifier: Linux-syscall-note
+      SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
+      SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, LGPL-2.1, LGPL-2.1+
+      Usage-Guidance:
+        Esta exceção é usada em conjunto com uma das SPDX-Licenses acima para
+        marcar arquivos de cabeçalho de API do espaço do usuário (uapi), para que
+        possam ser incluídos em código de aplicativo de espaço do usuário que não
+        esteja em conformidade com a GPL.
+        Para usar esta exceção, adicione-a com a palavra-chave WITH a um dos
+        identificadores na tag SPDX-Licenses:
+          SPDX-License-Identifier: <SPDX-License> WITH Linux-syscall-note
+      Exception-Text:
+        Texto completo da exceção
+
+Exemplos de formato de arquivo::
+
+      SPDX-Exception-Identifier: GCC-exception-2.0
+      SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.html
+      SPDX-Licenses: GPL-2.0, GPL-2.0+
+      Usage-Guidance:
+        A "GCC Runtime Library exception 2.0" é usada em conjunto com uma das
+        SPDX-Licenses acima para código importado da biblioteca de tempo de
+        execução (runtime) do GCC.
+        Para usar esta exceção, adicione-a com a palavra-chave WITH a um dos
+        identificadores na tag SPDX-Licenses:
+          SPDX-License-Identifier: <SPDX-License> WITH GCC-exception-2.0
+      Exception-Text:
+        Texto completo da exceção
+
+Todos os identificadores de licença e exceções SPDX devem ter um arquivo
+correspondente nos subdiretórios LICENSES. Isso é necessário para permitir a
+verificação por ferramentas (ex: checkpatch.pl) e para que as licenças estejam
+prontas para leitura e extração diretamente da fonte, o que é recomendado por
+várias organizações de FOSS (Software Livre e de Código Aberto), como a
+`iniciativa REUSE da FSFE <https://reuse.software/>`_.
+
+_`MODULE_LICENSE`
+-----------------
+
+   Módulos carregáveis do kernel também exigem uma tag MODULE_LICENSE(). Esta tag
+   não substitui as informações adequadas de licença do código-fonte
+   (SPDX-License-Identifier), nem é de forma alguma relevante para expressar ou
+   determinar a licença exata sob a qual o código-fonte do módulo é fornecido.
+
+   O único propósito desta tag é fornecer informações suficientes ao carregador
+   de módulos do kernel e às ferramentas de espaço do usuário sobre o módulo ser
+   software livre ou proprietário.
+
+   As strings de licença válidas para MODULE_LICENSE() são::
+
+      ============================= =============================================
+      "GPL"                         O módulo está licenciado sob a GPL versão 2.
+                                    Isso não expressa nenhuma distinção entre
+                                    GPL-2.0-only ou GPL-2.0-or-later. A informação
+                                    exata da licença só pode ser determinada por
+                                    meio das informações de licença nos arquivos
+                                    fonte correspondentes.
+
+      "GPL v2"                      O mesmo que "GPL". Existe por razões
+                                    históricas.
+
+      "GPL and additional rights"   Variante histórica para expressar que o fonte
+                                    do módulo possui licenciamento duplo sob uma
+                                    variante da GPL v2 e a licença MIT. Por favor,
+                                    não use em códigos novos.
+
+      "Dual MIT/GPL"                A maneira correta de expressar que o módulo
+                                    possui licenciamento duplo sob uma escolha de
+                                    variante GPL v2 ou licença MIT.
+
+      "Dual BSD/GPL"                O módulo possui licenciamento duplo sob uma
+                                    escolha de variante GPL v2 ou licença BSD. A
+                                    variante exata da licença BSD só pode ser
+                                    determinada por meio das informações de
+                                    licença nos arquivos fonte correspondentes.
+
+      "Dual MPL/GPL"                O módulo possui licenciamento duplo sob uma
+                                    escolha de variante GPL v2 ou Mozilla Public
+                                    License (MPL). A variante exata da licença
+                                    MPL só pode ser determinada por meio das
+                                    informações de licença nos arquivos fonte
+                                    correspondentes.
+
+      "Proprietary"                 O módulo está sob uma licença proprietária.
+                                    "Proprietary" deve ser entendido apenas como
+                                    "A licença não é compatível com GPLv2". Esta
+                                    string é exclusiva para módulos de terceiros
+                                    não compatíveis com GPL2 e não pode ser usada
+                                    para módulos que tenham seu código-fonte na
+                                    árvore do kernel. Módulos marcados dessa forma
+                                    contaminam (tainting) o kernel com a flag 'P'
+                                    quando carregados, e o carregador de módulos
+                                    recusa-se a vincular tais módulos a símbolos
+                                    exportados com EXPORT_SYMBOL_GPL().
+      ============================= =============================================

linux-7.2.3/Documentation/translations/pt_BR/process/maintainer-handbooks.rst

@@ -0,0 +1,22 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Notas sobre o processo de desenvolvimento de subsistemas e mantenedores
+=======================================================================
+
+O propósito deste documento é fornecer informações específicas de
+subsistemas que são suplementares ao manual geral do processo de
+desenvolvimento.
+:ref:`Documentation/process <development_process_main>`.
+
+Para desenvolvedores, veja abaixo todos os guias específicos de
+subsistemas conhecidos. Se o subsistema para o qual você está
+contribuindo não tiver um guia listado aqui, é recomendável buscar
+esclarecimentos sobre as questões levantadas em
+Documentation/maintainer/maintainer-entry-profile.rst.
+
+Para mantenedores, considere documentar requisitos adicionais e
+expectativas caso as submissões frequentemente deixem de atender
+a critérios específicos de submissão. Veja
+Documentation/maintainer/maintainer-entry-profile.rst.
+
+.. maintainers-profile-toc::

linux-7.2.3/Documentation/translations/pt_BR/process/maintainer-kvm-x86.rst

@@ -0,0 +1,435 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+KVM x86
+=======
+
+Prefácio
+--------
+
+O KVM se esforça para ser uma comunidade acolhedora; as contribuições de
+recém-chegados são valorizadas e incentivadas. Por favor, não se sinta
+desanimado ou intimidado pela extensão deste documento e pelas muitas
+regras/diretrizes que ele contém. Todo mundo comete erros e todo mundo já foi um
+novato em algum momento. Desde que você faça um esforço honesto para seguir as
+diretrizes do KVM x86, seja receptivo ao feedback e aprenda com os erros que
+cometer, você será recebido de braços abertos, não com tochas e forquilhas.
+
+(TL;DR)
+--------
+Testes são obrigatórios. Seja consistente com os estilos e padrões estabelecidos.
+
+Árvores
+-------
+O KVM x86 está atualmente em um período de transição: deixando de fazer parte da
+árvore principal do KVM para se tornar "apenas mais uma arquitetura KVM". Como tal,
+o KVM x86 está dividido entre a árvore principal do KVM,
+``git.kernel.org/pub/scm/virt/kvm/kvm.git``, e uma árvore específica para KVM x86,
+``github.com/kvm-x86/linux.git``.
+
+De modo geral, as correções (fixes) para o ciclo atual são aplicadas diretamente
+na árvore principal do KVM, enquanto todo o desenvolvimento para o próximo ciclo
+é roteado através da árvore do KVM x86. No caso improvável de uma correção para o
+ciclo atual ser roteada através da árvore do KVM x86, ela será aplicada à branch
+``fixes`` antes de seguir para a árvore principal do KVM.
+
+Note que espera-se que este período de transição dure bastante tempo, ou seja,
+será o status quo em um futuro próximo.
+
+Branches
+~~~~~~~~
+A árvore do KVM x86 é organizada em múltiplas branches de tópicos (topic
+branches). O objetivo de usar branches de tópicos mais granulares é facilitar o
+acompanhamento de uma área específica de desenvolvimento e limitar os danos
+colaterais de erros humanos e/ou commits com bugs; por exemplo, descartar o
+commit HEAD de uma branch de tópico não tem impacto nos hashes SHA1 de outros
+commits em andamento, e a necessidade de rejeitar um pull request devido a bugs
+atrasa apenas aquela branch de tópico específica.
+
+Todas as branches de tópicos, exceto a ``next`` e a ``fixes``, são incorporadas
+na ``next`` via um "Cthulhu merge" conforme a necessidade, ou seja, sempre que
+uma branch de tópico é atualizada. Como resultado, force pushes para a branch
+``next`` são comuns.
+
+Ciclo de Vida
+~~~~~~~~~~~~~
+As correções (fixes) destinadas ao lançamento atual, também conhecido como
+mainline, são normalmente aplicadas diretamente na árvore principal do KVM, ou
+seja, não passam pela árvore do KVM x86.
+
+As mudanças destinadas ao próximo lançamento são roteadas através da árvore do
+KVM x86. Pull requests (do KVM x86 para o KVM principal) são enviados para cada
+branch de tópico do KVM x86, normalmente na semana anterior à abertura da janela
+de merge por Linus, por exemplo, na semana seguinte ao rc7 para lançamentos
+"normais". Se tudo correr bem, as branches de tópicos são incorporadas ao pull
+request principal do KVM enviado durante a janela de merge de Linus.
+
+A árvore do KVM x86 não possui sua própria janela de merge oficial, mas há um
+"soft close" (fechamento flexível) por volta do rc5 para novos recursos, e um
+"soft close" por volta do rc6 para correções (para o próximo lançamento; veja
+acima para correções destinadas ao lançamento atual).
+
+Cronograma
+----------
+As submissões são normalmente revisadas e aplicadas em ordem FIFO (primeiro a
+entrar, primeiro a sair), com alguma margem de manobra para o tamanho de uma
+série, patches que estão "cache hot", etc. Correções (fixes), especialmente para
+o lançamento atual e/ou árvores estáveis (stable trees), têm prioridade na fila.
+Patches que serão aceitos através de uma árvore não-KVM (mais frequentemente
+através da árvore "tip") e/ou que possuam outros "acks"/revisões também ganham
+certa prioridade.
+
+Note que a grande maioria das revisões é feita entre o rc1 e o rc6,
+aproximadamente. O período entre o rc6 e o próximo rc1 é usado para colocar
+outras tarefas em dia, ou seja, o "silêncio de rádio" durante este período não é
+incomum.
+
+Pings para obter uma atualização de status são bem-vindos, mas tenha em mente o
+tempo do ciclo de lançamento atual e tenha expectativas realistas. Se você está
+dando um ping para aceitação — ou seja, não apenas para feedback ou uma
+atualização — por favor, faça tudo o que puder, dentro do razoável, para garantir
+que seus patches estejam prontos para o merge! Pings em séries que quebram o
+build ou falham em testes resultam em mantenedores infelizes!
+
+Desenvolvimento
+---------------
+
+Árvore/Branch Base
+~~~~~~~~~~~~~~~~~~
+Correções destinadas ao lançamento atual, também conhecido como mainline, devem
+ser baseadas em ``git://git.kernel.org/pub/scm/virt/kvm/kvm.git master``. Note
+que as correções não garantem inclusão automática no lançamento atual. Não
+existe uma regra única, mas tipicamente apenas correções para bugs que sejam
+urgentes, críticos e/ou que tenham sido introduzidos no lançamento atual devem
+ser destinadas ao lançamento atual.
+
+Todo o restante deve ser baseado em ``kvm-x86/next``, ou seja, não há
+necessidade de selecionar uma branch de tópico específica como base. Se houver
+conflitos e/ou dependências entre as branches de tópicos, é trabalho do
+mantenedor resolvê-los.
+
+A única exceção ao uso da ``kvm-x86/next`` como base é se um patch/série for uma
+série multi-arquitetura (multi-arch), ou seja, possuir modificações não triviais
+no código comum do KVM e/ou possuir mudanças mais do que superficiais no código
+de outras arquiteturas. Patches/séries multi-arquitetura devem, em vez disso,
+ser baseados em um ponto comum e estável no histórico do KVM, por exemplo, o
+release candidate no qual a ``kvm-x86 next`` se baseia. Se você não tiver
+certeza se um patch/série é verdadeiramente multi-arquitetura, erre pelo lado da
+cautela e trate-o como tal, ou seja, use uma base comum.
+
+Estilo de Codificação
+~~~~~~~~~~~~~~~~~~~~~
+Quando se trata de estilo, nomenclatura, padrões, etc., a consistência é a
+prioridade número um no KVM x86. Se tudo mais falhar, siga o que já existe.
+
+Com algumas ressalvas listadas abaixo, siga o estilo de codificação preferido
+dos mantenedores da árvore "tip" (:ref:`maintainer-tip-coding-style`), já que
+patches/séries frequentemente tocam tanto arquivos do KVM quanto arquivos x86
+não-KVM, ou seja, atraem a atenção de mantenedores do KVM *e* da árvore "tip".
+
+O uso de "reverse fir tree" (árvore de abeto invertida), também conhecido como
+"árvore de Natal invertida", para declarações de variáveis não é estritamente
+obrigatório, embora ainda seja preferido.
+
+Exceto por alguns casos excepcionais, não use comentários kernel-doc para
+funções. A grande maioria das funções "públicas" do KVM não são verdadeiramente
+públicas, pois se destinam apenas ao consumo interno do KVM (há planos para
+privatizar os headers e exports do KVM para reforçar isso).
+
+Comentários
+~~~~~~~~~~~
+Escreva comentários usando o modo imperativo e evite pronomes. Use comentários
+para fornecer uma visão geral de alto nível do código e/ou para explicar por
+que o código faz o que faz. Não reitere o que o código faz literalmente; deixe
+o código falar por si mesmo. Se o código em si for inescrutável, comentários
+não ajudarão.
+
+Referências ao SDM e ao APM
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Grande parte da base de código do KVM está diretamente ligada ao comportamento
+arquitetural definido no Manual de Desenvolvimento de Software (SDM) da Intel e
+no Manual do Programador de Arquitetura (APM) da AMD. O uso de "Intel SDM" e
+"AMD APM", ou até mesmo apenas "SDM" ou "APM", sem contexto adicional, é
+perfeitamente aceitável.
+
+Não faça referência a seções, tabelas, figuras, etc., por número, especialmente
+em comentários. Em vez disso, se necessário (veja abaixo), copie e cole o trecho
+relevante e referencie seções/tabelas/figuras pelo nome. Os layouts do SDM e do
+APM mudam constantemente e, portanto, os números/rótulos não são estáveis.
+
+De modo geral, não faça referência explícita nem copie e cole do SDM ou do APM
+em comentários. Com poucas exceções, o KVM *deve* respeitar o comportamento
+arquitetural; portanto, subentende-se que o comportamento do KVM está emulando o
+comportamento do SDM e/ou do APM. Note que fazer referência ao SDM/APM em
+changelogs para justificar a mudança e fornecer contexto é perfeitamente
+aceitável e incentivado.
+
+Shortlog
+~~~~~~~~
+O formato de prefixo preferencial é ``KVM: <topic>:``, onde ``<topic>`` é um dos
+seguintes::
+
+  - x86
+  - x86/mmu
+  - x86/pmu
+  - x86/xen
+  - selftests
+  - SVM
+  - nSVM
+  - VMX
+  - nVMX
+
+**NÃO use x86/kvm!** ``x86/kvm`` é usado exclusivamente para mudanças no Linux
+como convidado (guest) de um KVM, ou seja, para ``arch/x86/kernel/kvm.c``. Não
+use nomes de arquivos ou caminhos completos de arquivos como prefixo do
+assunto/shortlog.
+
+Note que estes não se alinham com as branches de tópicos (as branches de tópicos
+se preocupam muito mais com conflitos de código).
+
+Todos os nomes são sensíveis a maiúsculas e minúsculas! ``KVM: x86:`` é bom,
+``kvm: vmx:`` não é.
+
+Comece com letra maiúscula a primeira palavra da descrição condensada do patch,
+mas omita a pontuação final. Ex.::
+
+    KVM: x86: Fix a null pointer dereference in function_xyz()
+
+e não::
+
+    kvm: x86: fix a null pointer dereference in function_xyz.
+
+Se um patch tocar em múltiplos tópicos, suba na árvore conceitual para encontrar
+o primeiro pai comum (que geralmente é apenas ``x86``). Em caso de dúvida,
+``git log caminho/do/arquivo`` deve fornecer uma dica razoável.
+
+Novos tópicos surgem ocasionalmente, mas, por favor, inicie uma discussão na
+lista se desejar propor a introdução de um novo tópico; ou seja, não aja por
+conta própria.
+
+Veja :ref:`the_canonical_patch_format` para mais informações, com uma ressalva:
+não trate o limite de 70-75 caracteres como um limite absoluto e rígido. Em
+vez disso, use 75 caracteres como um limite firme, mas não rígido, e use 80
+caracteres como um limite intransponível. Ou seja, permita que o shortlog
+ultrapasse alguns caracteres do limite padrão se você tiver um bom motivo para
+fazê-lo.
+
+Changelog
+~~~~~~~~~
+O mais importante: escreva os changelogs usando o modo imperativo e evite o uso
+de pronomes.
+
+Veja :ref:`describe_changes` para mais informações, com uma ressalva: comece com
+uma breve descrição das mudanças reais e, em seguida, apresente o contexto e o
+histórico. Note! Esta ordem entra em conflito direto com a abordagem preferida
+da árvore "tip"! Por favor, siga o estilo preferido da árvore "tip" ao enviar
+patches que visam primariamente o código de arch/x86 que _NÃO_ seja código KVM.
+
+Declarar o que um patch faz antes de mergulhar nos detalhes é preferido pelo KVM
+x86 por vários motivos. Primeiro e mais importante, qual código está sendo
+realmente alterado é, reconhecidamente, a informação mais importante e,
+portanto, essa informação deve ser fácil de encontrar. Changelogs que escondem
+"o que está mudando de fato" em uma única linha após 3 ou mais parágrafos de
+histórico tornam muito difícil encontrar essa informação.
+
+Para uma revisão inicial, pode-se argumentar que "o que está quebrado" é mais
+importante, mas para uma leitura rápida de logs e arqueologia do git, os
+detalhes minuciosos importam cada vez menos. Por exemplo, ao fazer uma série de
+"git blame", os detalhes de cada mudança ao longo do caminho são inúteis; os
+detalhes só importam para o culpado. Fornecer "o que mudou" facilita determinar
+rapidamente se um commit pode ou não ser de interesse.
+
+Outro benefício de declarar "o que está mudando" primeiro é que quase sempre é
+possível declarar "o que está mudando" em uma única frase. Por outro lado,
+exceto pelos bugs mais simples, todos exigem várias frases ou parágrafos para
+descrever totalmente o problema. Se tanto "o que está mudando" quanto "qual é o
+bug" forem super curtos, a ordem não importa. Mas se um for mais curto (quase
+sempre o "o que está mudando"), então cobrir o mais curto primeiro é vantajoso
+porque é menos inconveniente para leitores/revisores que têm uma preferência de
+ordenação estrita. Ex: ter que pular uma frase para chegar ao contexto é menos
+doloroso do que ter que pular três parágrafos para chegar ao "o que está
+mudando".
+
+Correções (Fixes)
+~~~~~~~~~~~~~~~~~
+Se uma mudança corrige um bug do KVM/kernel, adicione uma tag Fixes:, mesmo que
+a mudança não precise ser portada (backported) para kernels estáveis, e mesmo
+que a mudança corrija um bug em uma versão mais antiga.
+
+Por outro lado, se uma correção realmente precisar de backport, marque
+explicitamente o patch com "Cc: stable@vger.kernel.org" (embora o e-mail em si
+não precise enviar cópia para a lista stable); o KVM x86 opta por não realizar
+o backport automático de tags Fixes: por padrão. Alguns patches selecionados
+automaticamente são portados, mas exigem aprovação explícita do mantenedor
+(pesquise por MANUALSEL).
+
+Referências a Funções
+~~~~~~~~~~~~~~~~~~~~~
+Quando uma função for mencionada em um comentário, changelog ou shortlog (ou em
+qualquer outro lugar, aliás), use o formato ``nome_da_funcao()``. Os parênteses
+fornecem contexto e removem a ambiguidade da referência.
+
+Testes
+------
+No mínimo, *todos* os patches de uma série devem compilar sem erros para
+KVM_INTEL=m, KVM_AMD=m e KVM_WERROR=y. Compilar cada combinação possível de
+Kconfigs não é viável, mas quanto mais, melhor. KVM_SMM, KVM_XEN, PROVE_LOCKING
+e X86_64 são opções (knobs) particularmente interessantes para se testar.
+
+A execução de KVM selftests e KVM-unit-tests também é obrigatória (e, para
+afirmar o óbvio, os testes precisam passar). A única exceção é para mudanças
+que tenham probabilidade insignificante de afetar o comportamento em tempo de
+execução, por exemplo, patches que apenas modificam comentários. Sempre que
+possível e relevante, o teste tanto em Intel quanto em AMD é fortemente
+preferido. A inicialização de uma VM real é incentivada, mas não obrigatória.
+
+Para mudanças que tocam o código de shadow paging do KVM, executar com o TDP
+(EPT/NPT) desabilitado é obrigatório. Para mudanças que afetam o código comum da
+MMU do KVM, a execução com o TDP desabilitado é fortemente incentivada. Para
+todas as outras mudanças, se o código sendo modificado depender de e/ou
+interagir com um parâmetro de módulo (module param), o teste com as
+configurações relevantes é obrigatório.
+
+Note que o KVM selftests e o KVM-unit-tests possuem falhas conhecidas. Se você
+suspeitar que uma falha não se deve às suas alterações, verifique se a *exata
+mesma* falha ocorre com e sem as suas mudanças.
+
+Mudanças que tocam a documentação em reStructuredText, ou seja, arquivos .rst,
+devem compilar o htmldocs de forma limpa, ou seja, sem novos avisos (warnings)
+ou erros.
+
+Se você não puder testar totalmente uma mudança, por exemplo, devido à falta de
+hardware, declare claramente qual nível de teste você foi capaz de realizar,
+por exemplo, na cover letter (carta de apresentação).
+
+Novos Recursos
+~~~~~~~~~~~~~~
+Com uma exceção, novos recursos *devem* vir acompanhados de cobertura de testes.
+Testes específicos do KVM não são estritamente obrigatórios, por exemplo, se a
+cobertura for fornecida ao executar uma VM convidada (guest) suficientemente
+habilitada, ou ao executar um selftest de kernel relacionado em uma VM, mas
+testes dedicados do KVM são preferidos em todos os casos. Casos de teste
+negativos, em particular, são obrigatórios para a habilitação de novos recursos
+de hardware, já que fluxos de erro e exceção raramente são exercitados
+simplesmente ao executar uma VM.
+
+A única exceção a esta regra é se o KVM estiver simplesmente anunciando suporte
+para um recurso via KVM_GET_SUPPORTED_CPUID, ou seja, para instruções/recursos
+que o KVM não pode impedir um convidado de usar e para os quais não há uma
+habilitação real.
+
+Note que "novos recursos" não significa apenas "novos recursos de hardware"!
+Novos recursos que não podem ser bem validados usando os KVM selftests e/ou
+KVM-unit-tests existentes devem vir acompanhados de testes.
+
+Enviar o desenvolvimento de novos recursos sem testes para obter feedback
+antecipado é mais do que bem-vindo, mas tais submissões devem ser marcadas como
+RFC, e a carta de apresentação (cover letter) deve declarar claramente que tipo
+de feedback é solicitado/esperado. Não abuse do processo de RFC; as RFCs
+normalmente não receberão uma revisão profunda.
+
+Correções de Bugs
+~~~~~~~~~~~~~~~~~
+Exceto por bugs "óbvios" encontrados por inspeção, as correções devem vir
+acompanhadas de um reprodutor (reproducer) para o bug que está sendo corrigido.
+Em muitos casos, o reprodutor é implícito, por exemplo, para erros de build e
+falhas de teste, mas ainda assim deve estar claro para os leitores o que está
+quebrado e como verificar a correção. Alguma margem de manobra é dada para
+bugs encontrados através de cargas de trabalho ou testes não públicos, mas a
+disponibilização de testes de regressão para tais bugs é fortemente preferida.
+
+Em geral, testes de regressão são preferidos para qualquer bug que não seja
+trivial de ser atingido. Por exemplo, mesmo que o bug tenha sido originalmente
+encontrado por um fuzzer como o syzkaller, um teste de regressão direcionado
+pode ser justificável se o bug exigir que se atinja uma condição de corrida do
+tipo "uma em um milhão".
+
+Note que os bugs do KVM raramente são urgentes *e* não triviais de reproduzir.
+Pergunte a si mesmo se um bug é realmente o fim do mundo antes de enviar uma
+correção sem um reprodutor.
+
+Postagem
+--------
+
+Links
+~~~~~
+Não faça referência explícita a relatórios de bugs, versões anteriores de um
+patch/série, etc., através de cabeçalhos ``In-Reply-To:``. O uso de
+``In-Reply-To:`` torna-se uma bagunça infernal para grandes séries e/ou quando
+o número de versões aumenta, e o ``In-Reply-To:`` é inútil para qualquer
+pessoa que não tenha a mensagem original, por exemplo, se alguém não estava
+em cópia (Cc) no relatório do bug ou se a lista de destinatários mudar entre
+as versões.
+
+Para vincular a um relatório de bug, versão anterior ou qualquer coisa de
+interesse, use links do lore. Para referenciar versão(ões) anterior(es), de modo
+geral, não inclua um Link: no changelog, pois não há necessidade de registrar o
+histórico no git; ou seja, coloque o link na carta de apresentação (cover
+letter) ou na seção que o git ignora. Forneça um Link: formal para relatórios
+de bugs e/ou discussões que levaram ao patch. O contexto de por que uma mudança
+foi feita é altamente valioso para futuros leitores.
+
+Base do Git (Git Base)
+~~~~~~~~~~~~~~~~~~~~~~
+Se você estiver usando o git versão 2.9.0 ou posterior (Googlers, isso inclui
+todos vocês!), use ``git format-patch`` com a flag ``--base`` para incluir
+automaticamente as informações da árvore base nos patches gerados.
+
+Note que ``--base=auto`` funciona conforme o esperado se, e somente se, o
+upstream de uma branch estiver definido para a branch de tópico base; por
+exemplo, ele fará a coisa errada se o seu upstream estiver definido para o seu
+repositório pessoal para fins de backup. Uma solução "auto" alternativa é
+derivar os nomes das suas branches de desenvolvimento com base no seu tópico
+KVM x86 e alimentar isso no ``--base``. Por exemplo,
+``x86/pmu/minha_branch`` e, em seguida, escrever um pequeno wrapper para
+extrair ``pmu`` do nome da branch atual para resultar em ``--base=x/pmu``, onde
+``x`` é o nome que seu repositório usa para rastrear o remoto do KVM x86.
+
+Postagem Conjunta de Testes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+KVM selftests que estão associados a mudanças no KVM, por exemplo, testes de
+regressão para correções de bugs, devem ser postados junto com as mudanças do
+KVM como uma única série. As regras padrão do kernel para bissecção (bisection)
+se aplicam, ou seja, mudanças no KVM que resultem em falhas de teste devem ser
+ordenadas após as atualizações dos selftests e, vice-versa, novos testes que
+falhem devido a bugs do KVM devem ser ordenados após as correções do KVM.
+
+KVM-unit-tests devem *sempre* ser postados separadamente. Ferramentas, como o
+b4 am, não sabem que o KVM-unit-tests é um repositório separado e ficam
+confusas quando os patches de uma série se aplicam a árvores diferentes. Para
+vincular os patches do KVM-unit-tests aos patches do KVM, poste primeiro as
+mudanças do KVM e, em seguida, forneça um link do lore para o patch/série do
+KVM no(s) patch(es) do KVM-unit-tests.
+
+Notificações
+------------
+Quando um patch/série é oficialmente aceito, um e-mail de notificação será
+enviado em resposta à postagem original (carta de apresentação para séries de
+múltiplos patches). A notificação incluirá a árvore e a branch de tópico,
+juntamente com os SHA1s dos commits dos patches aplicados.
+
+Se um subconjunto de patches for aplicado, isso será claramente declarado na
+notificação. A menos que seja dito o contrário, subentende-se que quaisquer
+patches na série que não foram aceitos precisam de mais trabalho e devem ser
+enviados em uma nova versão.
+
+Se, por algum motivo, um patch for descartado após ter sido oficialmente
+aceito, uma resposta será enviada ao e-mail de notificação explicando o porquê
+do descarte, bem como os próximos passos.
+
+Estabilidade de SHA1
+~~~~~~~~~~~~~~~~~~~~
+Os SHA1s não têm garantia de serem 100% estáveis até que cheguem na árvore do
+Linus! Um SHA1 é *geralmente* estável uma vez que a notificação tenha sido
+enviada, mas imprevistos acontecem. Na maioria dos casos, uma atualização no
+e-mail de notificação será fornecida se o SHA1 de um patch aplicado mudar. No
+entanto, em alguns cenários, por exemplo, se todas as branches do KVM x86
+precisarem de rebase, as notificações individuais não serão enviadas.
+
+Vulnerabilidades
+----------------
+Bugs que podem ser explorados pelo convidado (guest) para atacar o hospedeiro
+(host) (kernel ou espaço do usuário), ou que podem ser explorados por uma VM
+aninhada (nested) contra o *seu* próprio hospedeiro (L2 atacando L1), são de
+interesse particular para o KVM. Por favor, siga o protocolo em
+:ref:`securitybugs` se você suspeitar que um bug possa levar a um escape,
+vazamento de dados, etc.

linux-7.2.3/Documentation/translations/pt_BR/process/maintainer-netdev.rst

@@ -0,0 +1,596 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Subsistema de Rede do Linux (netdev)
+=====================================
+
+tl;dr
+-----
+
+- **Direcione seu patch para uma árvore** – use ``[PATCH net]``para correções
+  ou ``[PATCH net-next]`` para novas funcionalidades.
+- **Tag Fixes** – para correções, a tag ``Fixes:`` é obrigatória,
+  independentemente da árvore de destino.
+- **Tamanho da série** – não envie séries grandes (> 15 patches);divida-as em
+  partes menores.
+- **Intervalo de envio** – não reenvie seus patches dentro de um período de 24
+  horas.
+- **Reverse xmas tree** – organize as declarações de variáveis locais da mais
+  longa para a mais curta.
+
+netdev
+------
+A **netdev** é a lista de discussão para todos os assuntos do Linux relacionados
+a rede. Isso inclui qualquer item encontrado em ``net/`` (ex: código principal
+como IPv6) e  em ``drivers/net`` (ex: drivers específicos de hardware) na árvore
+de diretórios do Linux.
+
+Note que alguns subsistemas (ex: drivers de rede sem fio/wireless), que possuem
+um  alto volume de tráfego, possuem suas próprias listas de discussão e árvores
+específicas.
+
+Como muitas outras listas de discussão do Linux, a lista netdev é hospedada no
+`kernel.org <https://www.kernel.org/>`_, com arquivos disponíveis em
+https://lore.kernel.org/netdev/.
+
+À exceção dos subsistemas mencionados anteriormente, todo o desenvolvimento de
+rede  do Linux (ex: RFCs, revisões, comentários, etc.) ocorre na **netdev**.
+
+Ciclo de Desenvolvimento
+------------------------
+
+Aqui está um pouco de informação contextual sobre a cadência de desenvolvimento
+do Linux. Cada nova versão (release) inicia-se com uma "janela de mesclagem"
+(*merge window*) de duas semanas, onde os mantenedores principais enviam suas
+novas implementações para o Linus para incorporação na árvore principal
+(*mainline tree*).
+
+Após as duas semanas, a janela de mesclagem é fechada e a versão é
+nomeada/etiquetada  como ``-rc1``. Nenhuma funcionalidade nova é incorporada à
+árvore principal após  isso -- espera-se apenas correções (*fixes*) para o
+conteúdo da rc1.
+
+Após cerca de uma semana coletando correções para a rc1, a rc2 é lançada. Isso
+se  repete semanalmente até a rc7 (tipicamente; às vezes rc6 se o ritmo estiver
+calmo, ou rc8 se houver muita instabilidade); uma semana após a última vX.Y-rcN
+ser  concluída, a versão oficial vX.Y é lançada.
+
+Para descobrir em que ponto do ciclo estamos agora - carregue a página da
+mainline (Linus) aqui:
+
+  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+
+e observe o topo da seção de "tags". Se for rc1, estamos no início do ciclo
+de desenvolvimento. Se a rc7 foi marcada há uma semana, então um lançamento
+é provavelmente iminente. Se a tag mais recente for uma tag de lançamento
+final (sem o sufixo ``-rcN``) - muito provavelmente estamos em uma janela de
+mesclagem (*merge window*) e o ``net-next`` está fechado.
+
+Árvores git e fluxo de patches
+------------------------------
+
+Existem duas árvores de rede (repositórios git) em jogo. Ambas são coordenadas
+por David Miller, o mantenedor principal de rede. Há a árvore ``net``e a árvore
+``net-next``. Como você provavelmente pode adivinhar pelos nomes, a árvore
+``net`` é para correções de código existente já na árvore mainline de Linus, e a
+``net-next`` é para onde o novo código vai para o lançamento futuro.
+Você pode encontrar as árvores aqui:
+
+- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
+- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
+
+Relacionando isso ao desenvolvimento do kernel: no início da janela de mesclagem
+(*merge window*) de 2 semanas, a árvore ``net-next`` será fechada, sem novas
+mudanças ou funcionalidades. O conteúdo novo acumulado nas últimas 10 semanas
+será passado para a mainline/Linus via um *pull request* para a vX.Y ao mesmo
+tempo, a árvore ``net`` começará a acumular correções para este conteúdo enviado
+relacionado à vX.Y.
+
+Um anúncio indicando quando a ``net-next`` foi fechada é geralmente enviado para
+a netdev, mas sabendo o que foi dito acima, você pode prever isso com
+antecedência.
+
+.. warning::
+
+  Não envie novo conteúdo para a ``net-next`` para a netdev durante o período
+  em que a árvore ``net-next`` estiver fechada.
+
+Patches RFC enviados apenas para revisão são obviamente bem-vindos a qualquer
+momento (use ``--subject-prefix='RFC net-next'`` com ``git format-patch``).
+
+Pouco depois das duas semanas terem passado (e a vX.Y-rc1 ser lançada), a árvore
+para a ``net-next`` reabre para coletar conteúdo para o próximo lançamento
+(vX.Y+1).
+
+Se você não estiver inscrito na netdev e/ou simplesmente não tiver certeza se a
+``net-next`` já reabriu, basta verificar o link do repositório git da
+``net-next`` acima para quaisquer novos *commits* relacionados à rede. Você
+também pode verificar o seguinte site para o status atual:
+
+  https://netdev.bots.linux.dev/net-next.html
+
+A árvore ``net`` continua a coletar correções para o conteúdo da vX.Y e é
+enviada de volta para Linus em intervalos regulares (~semanais). Isso significa
+que o foco da ``net`` é a estabilização e correções de bugs.
+
+Finalmente, a vX.Y é lançada e todo o ciclo recomeça.
+
+Revisão de patches da netdev
+----------------------------
+
+Status do patch
+~~~~~~~~~~~~~~~
+
+O status de um patch pode ser verificado olhando a fila principal do patchwork
+para a netdev:
+
+  https://patchwork.kernel.org/project/netdevbpf/list/
+
+O campo "State" informará exatamente onde as coisas estão com o seu patch:
+
+=================  ============================================================
+Estado do patch    Descrição
+=================  ============================================================
+New, Under review  revisão pendente, o patch está na fila do mantenedor
+                   para revisão; os dois estados são usados alternadamente
+                   (dependendo do co-mantenedor exato que estiver lidando
+                   com o patchwork no momento)
+Accepted           o patch foi aplicado à árvore de rede apropriada,
+                   isso é geralmente definido de forma automática pelo pw-bot
+Needs ACK          aguardando um "ack" de um especialista da área
+                   ou testes
+Changes requested  o patch não passou na revisão, espera-se uma nova
+                   revisão com mudanças apropriadas no código e na mensagem
+                   de commit
+Rejected           o patch foi rejeitado e não se espera uma nova
+                   revisão
+Not applicable     espera-se que o patch seja aplicado fora do
+                   subsistema de rede
+Awaiting upstream  o patch deve ser revisado e tratado pelo sub-mantenedor
+                   apropriado, que o enviará para as árvores de rede;
+                   patches definidos como ``Awaiting upstream`` no patchwork
+                   da netdev geralmente permanecerão neste estado,
+                   independentemente de o sub-mantenedor ter solicitado
+                   mudanças, aceito ou rejeitado o patch
+Deferred           o patch precisa ser reenviado mais tarde, geralmente
+                   devido a alguma dependência ou porque foi enviado para
+                   uma árvore fechada
+Superseded         uma nova versão do patch foi enviada, geralmente
+                   definido pelo pw-bot
+RFC                não deve ser aplicado, geralmente não está na
+                   fila de revisão do mantenedor; o pw-bot pode definir
+                   patches para este estado automaticamente com base nas
+                   tags do assunto
+=================  ============================================================
+
+Os patches são indexados pelo cabeçalho ``Message-ID`` dos e-mails que os
+transportaram; portanto, se você tiver problemas para encontrar seu patch,
+anexe o valor do ``Message-ID`` à URL acima.
+
+Atualizando o status do patch
+-----------------------------
+
+Colaboradores e revisores não têm permissões para atualizar o estado do patch
+diretamente no patchwork. O Patchwork não expõe muitas informações sobre o
+histórico do estado dos patches; portanto, ter várias pessoas atualizando o
+estado leva a confusões.
+
+Em vez de delegar permissões do patchwork, a netdev usa um robô de e-mail
+simples (bot) que procura por comandos/linhas especiais dentro dos e-mails
+enviados para a lista de discussão. Por exemplo, para marcar uma série como
+Mudanças Solicitadas (*Changes Requested*), é necessário enviar a seguinte
+linha em qualquer lugar na thread do e-mail::
+
+  pw-bot: changes-requested
+
+Como resultado, o bot definirá toda a série como Mudanças Solicitadas. Isso
+pode ser útil quando o autor descobre um bug em sua própria série e deseja
+evitar que ela seja aplicada.
+
+O uso do bot é totalmente opcional; em caso de dúvida, ignore completamente a
+existência dele. Os mantenedores classificarão e atualizarão o estado dos
+patches por conta própria. Nenhum e-mail deve ser enviado à lista com o
+propósito principal de se comunicar com o bot; os comandos do bot devem ser
+vistos como metadados.
+
+O uso do bot é restrito aos autores dos patches (o cabeçalho ``From:`` no envio
+do patch e no comando deve coincidir!), mantenedores do código modificado de
+acordo com o arquivo MAINTAINERS (novamente, o ``From:`` deve coincidir
+com a entrada no MAINTAINERS) e alguns revisores seniores.
+
+O bot registra sua atividade aqui:
+
+  https://netdev.bots.linux.dev/pw-bot.html
+
+Prazos de revisão
+~~~~~~~~~~~~~~~~~
+
+De modo geral, os patches são triados rapidamente (em menos de 48h). Mas
+seja paciente; se o seu patch estiver ativo no patchwork (ou seja, listado
+na lista de patches do projeto), as chances de ele ter sido esquecido são
+próximas de zero.
+
+O alto volume de desenvolvimento na netdev faz com que os revisores encerrem
+discussões de forma relativamente rápida. É muito improvável que novos
+comentários e respostas cheguem após uma semana de silêncio. Se um
+patch não estiver mais ativo no patchwork e a thread ficar inativa por mais de
+uma semana - esclareça os próximos passos e/ou envie a próxima versão.
+
+Especificamente para envios de RFC, se ninguém responder em uma semana  ou os
+revisores perderam o envio ou não têm opiniões fortes a respeito. Se o código
+estiver pronto, reenvie como um PATCH.
+
+E-mails dizendo apenas "ping" ou "bump" são considerados rudes. Se você não
+conseguir identificar o status do patch pelo patchwork ou onde a discussão
+parou - descreva sua melhor suposição e pergunte se ela está correta. Por
+exemplo::
+
+  Não entendo quais são os próximos passos. A Pessoa X parece estar  descontente
+  com A; devo fazer B e enviar novamente os patches?
+
+.. _Solicitações de mudanças:
+
+Mudanças solicitadas
+~~~~~~~~~~~~~~~~~~~~
+
+Patches marcados como ``Changes Requested`` precisam ser revisados. A nova
+versão deve vir com um registro de alterações (changelog),
+preferencialmente incluindo links para as postagens anteriores, por exemplo::
+
+  [PATCH net-next v3] net: faz as vacas dizerem "muuu"
+
+  Mesmo os usuários que não bebem leite apreciam ouvir as vacas dizendo
+  "muuu".
+
+  A quantidade de mugidos dependerá da taxa de pacotes, portanto, deve
+  corresponder muito bem ao ciclo diurno.
+
+  Signed-off-by: Joe Defarmer <joe@barn.org>
+  ---
+  v3:
+    - adicionada uma nota sobre a flutuação do mugido conforme a hora
+      do dia na
+      mensagem de commit
+  v2: https://lore.kernel.org/netdev/123themessageid@barn.org/
+    - corrigido argumento ausente na kernel doc para netif_is_bovine()
+    - corrigido vazamento de memória (memory leak) em
+    netdev_register_cow()
+  v1: https://lore.kernel.org/netdev/456getstheclicks@barn.org/
+
+A mensagem de commit deve ser revisada para responder a quaisquer perguntas que
+os revisores tenham feito em discussões anteriores. Ocasionalmente, a
+atualização da mensagem de commit será a única mudança na nova versão.
+
+Reenvios parciais
+~~~~~~~~~~~~~~~~~
+
+Por favor, sempre reenvie a série completa de patches e certifique-se de
+numerar seus patches de forma que fique claro que este é o conjunto mais
+recente e completo de patches que pode ser aplicado. Não tente reenviar apenas
+os patches que foram alterados.
+
+Lidando com patches aplicados incorretamente
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ocasionalmente, uma série de patches é aplicada antes de receber feedback
+crítico, ou a versão errada de uma série é aplicada.
+
+Não é possível fazer o patch desaparecer uma vez que ele foi enviado (pushed);
+o histórico de commits nas árvores netdev é imutável. Por favor, envie versões
+incrementais sobre o que foi mesclado para corrigir os patches da maneira que
+eles ficariam se a sua série de patches mais recente fosse mesclada.
+
+Em casos onde uma reversão completa (revert) é necessária, a reversão deve ser
+enviada como um patch para a lista com uma mensagem de commit explicando os
+problemas técnicos com o commit revertido. Reversões devem ser usadas como
+último recurso, quando a mudança original está completamente errada; correções
+incrementais são preferidas.
+
+Árvore estável
+~~~~~~~~~~~~~~
+
+Embora antigamente as submissões para a netdev não devessem carregar tags
+explícitas ``CC: stable@vger.kernel.org``, esse não é mais o caso hoje em dia.
+Por favor, siga as regras padrão de estabilidade em
+``Documentation/process/stable-kernel-rules.rst``, e certifique-se de incluir as
+tags Fixes apropriadas!
+
+Correções de segurança
+~~~~~~~~~~~~~~~~~~~~~~
+
+Não envie e-mails diretamente para os mantenedores da netdev se você acha que
+descobriu um bug que possa ter possíveis implicações de segurança. O atual
+mantenedor da netdev tem solicitado consistentemente que as pessoas usem as
+listas de discussão e não entrem em contato diretamente. Se você não estiver
+de acordo com isso, considere enviar um e-mail para security@kernel.org ou
+ler sobre http://oss-security.openwall.org/wiki/mailing-lists/distros como
+possíveis mecanismos alternativos.
+
+Envio conjunto de mudanças em componentes de espaço do usuário
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+O código de espaço do usuário (*user space*) que exercita funcionalidades do
+kernel deve ser enviado juntamente com os patches do kernel. Isso dá aos
+revisores a chance de ver como qualquer nova interface é usada e quão
+bem ela funciona.
+
+Quando as ferramentas de espaço do usuário residem no próprio repositório do
+kernel, todas as alterações devem geralmente vir em uma única série. Se a série
+se tornar muito grande ou se o projeto de espaço do usuário não for revisado na
+netdev, inclua um link para um repositório público onde os patches de espaço do
+usuário possam ser vistos.
+
+No caso de ferramentas de espaço do usuário residirem em um repositório
+separado, mas serem revisadas na netdev (por exemplo, patches para ferramentas
+``iproute2``), os patches do kernel e do espaço do usuário devem formar séries
+(threads) separadas quando postados na lista de discussão, por exemplo::
+
+  [PATCH net-next 0/3] net: carta de apresentação de alguma funcionalidade
+   └─ [PATCH net-next 1/3] net: preparação para alguma funcionalidade
+   └─ [PATCH net-next 2/3] net: implementação de alguma funcionalidade
+   └─ [PATCH net-next 3/3] selftest: net: alguma funcionalidade
+
+  [PATCH iproute2-next] ip: adiciona suporte para alguma funcionalidade
+
+A postagem em uma única thread é desencorajada porque confunde o patchwork
+(a partir da versão 2.2.2 do patchwork).
+
+Envio conjunto de selftests
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Os selftests devem fazer parte da mesma série que as mudanças de código.
+Especificamente para correções, tanto a mudança de código quanto o teste
+relacionado devem ir para a mesma árvore (os testes podem não ter uma tag
+Fixes, o que é esperado). Misturar mudanças de código e mudanças de teste em
+um único commit é desencorajado.
+
+Preparando as mudanças
+----------------------
+
+Atenção aos detalhes é importante. Releia seu próprio trabalho como se você
+fosse o revisor. Você pode começar usando o ``checkpatch.pl``, talvez até com
+a flag ``--strict``. Mas não seja robótico e irracional ao fazer isso. Se sua
+mudança for uma correção de bug, certifique-se de que seu log de commit indique
+o sintoma visível para o usuário final, a razão subjacente de por que isso
+acontece e, se necessário, explique por que a correção proposta é a melhor
+maneira de resolver as coisas. Não corrompa espaços em branco e, como é comum,
+não use recuos incorretos em argumentos de função que abrangem várias linhas.
+Se for o seu primeiro patch, envie-o para si mesmo por e-mail para que você
+possa testar a aplicação em uma árvore sem patches para confirmar que a
+infraestrutura não o danificou.
+
+Finalmente, volte e leia ``Documentation/process/submitting-patches.rst``
+para ter certeza de que não está repetindo algum erro comum documentado lá.
+
+Indicando a árvore de destino
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Para ajudar os mantenedores e os bots de CI, você deve marcar explicitamente
+qual árvore seu patch tem como alvo. Supondo que você use git, utilize a flag
+de prefixo::
+
+  git format-patch --subject-prefix='PATCH net-next' inicio..fim
+
+Use ``net`` em vez de ``net-next`` (sempre em letras minúsculas) no comando
+acima para conteúdos de correção de bugs da árvore ``net``.
+
+Dividindo o trabalho em patches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Coloque-se no lugar do revisor. Cada patch é lido separadamente e, portanto,
+deve constituir um passo compreensível em direção ao seu objetivo declarado.
+
+Evite enviar séries com mais de 15 patches. Séries maiores levam mais tempo
+para serem revisadas, pois os revisores adiarão a análise até encontrarem um
+grande bloco de tempo disponível. Uma série pequena pode ser revisada em pouco
+tempo, então os mantenedores simplesmente a revisam de imediato. Como resultado,
+uma sequência de séries menores é mesclada mais rapidamente e com melhor
+cobertura de revisão. Reenviar séries grandes também aumenta o tráfego na lista
+de discussão.
+
+Limitar patches pendentes na lista de discussão
+-----------------------------------------------
+
+Evite ter mais de 15 patches, em todas as séries, pendentes de revisão na lista
+de discussão para uma única árvore. Em outras palavras, um máximo de 15 patches
+sob revisão na ``net`` e um máximo de 15 patches sob revisão na ``net-next``.
+
+Este limite tem o objetivo de focar o esforço do desenvolvedor nos testes dos
+patches antes da revisão upstream, auxiliando a qualidade das submissões
+upstream e aliviando a carga sobre os revisores.
+
+Ordenação de variáveis locais ("árvore invertida", "RCS")
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A netdev tem uma convenção para ordenar variáveis locais em funções. Ordene as
+linhas de declaração de variáveis da mais longa para a mais curta, por exemplo::
+
+  struct scatterlist *sg;
+  struct sk_buff *skb;
+  int err, i;
+
+Se houver dependências entre as variáveis que impeçam a ordenação, mova a
+inicialização para fora da linha de declaração.
+
+Precedência de formatação
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ao trabalhar em código existente que utiliza formatação não padrão, faça com
+que seu código siga as diretrizes mais recentes, para que, eventualmente,
+todo o código no domínio da netdev esteja no formato preferido.
+
+Uso de construções gerenciadas por dispositivo e cleanup.h
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Historicamente, a netdev permanece cética em relação às promessas de todas as
+APIs de "auto-limpeza" (auto-cleanup), incluindo até mesmo os auxiliares
+``devm_``. Eles não são o estilo preferido de implementação, apenas um estilo
+aceitável.
+
+O uso de ``guard()`` é desencorajado em qualquer função com mais de 20 linhas;
+``scoped_guard()`` é considerado mais legível. O uso de lock/unlock normal
+ainda é (levemente) preferido.
+
+Construções de limpeza de baixo nível (como ``__free()``) podem ser usadas ao
+construir APIs e auxiliares, especialmente iteradores com escopo. No entanto, o
+uso direto de ``__free()`` dentro do núcleo de rede (networking core) e drivers
+é desencorajado. Orientações semelhantes se aplicam à declaração de variáveis
+no meio da função.
+
+Patches de limpeza (Clean-up patches)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A netdev desencoraja patches que realizam limpezas simples que não estejam no
+contexto de outro trabalho. Por exemplo:
+
+* Tratar avisos do ``checkpatch.pl`` e outros avisos triviais de estilo de
+  codificação
+* Tratar problemas de Ordenação de variáveis locais
+* Conversões para APIs gerenciadas por dispositivo (auxiliares ``devm_``)
+
+Isso ocorre porque se considera que a agitação (*churn*) que tais mudanças
+produzem tem um custo maior do que o valor de tais limpezas.
+
+Por outro lado, correções de ortografia e gramática não são desencorajadas.
+
+Reenviando após a revisão
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Aguarde pelo menos 24 horas entre as postagens. Isso garantirá que revisores de
+todas as localizações geográficas tenham a chance de se manifestar. Não espere
+muito tempo (semanas) entre as postagens, pois isso tornará mais difícil para
+os revisores lembrarem de todo o contexto.
+
+Certifique-se de tratar todo o feedback em sua nova postagem. Não envie uma
+nova versão do código se a discussão sobre a versão anterior ainda estiver em
+andamento, a menos que seja instruído diretamente por um revisor.
+
+A nova versão dos patches deve ser postada como uma thread separada, não como
+uma resposta à postagem anterior. O registro de alterações (changelog) deve
+incluir um link para a postagem anterior (veja :ref:`Solicitações
+de mudanças`).
+
+Testes
+------
+
+Nível de teste esperado
+~~~~~~~~~~~~~~~~~~~~~~~
+
+No mínimo, suas alterações devem passar por uma compilação ``allyesconfig`` e
+uma ``allmodconfig`` com ``W=1`` definido, sem novos avisos ou falhas.
+
+O ideal é que você tenha feito testes em tempo de execução específicos para sua
+alteração, e que a série de patches contenha um conjunto de selftests do kernel
+para ``tools/testing/selftests/net`` ou usando o framework KUnit.
+
+Espera-se que você teste suas alterações no topo da árvore de rede relevante
+(``net`` ou ``net-next``) e não, por exemplo, em uma árvore estável ou na
+``linux-next``.
+
+Verificações do patchwork
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As verificações (*checks*) no patchwork são, em sua maioria, wrappers simples
+em torno de scripts existentes do kernel; as fontes estão disponíveis em:
+
+https://github.com/linux-netdev/nipa/tree/master/tests
+
+**Não** envie seus patches apenas para executá-los nas verificações. Você deve
+garantir que seus patches estejam prontos, testando-os localmente antes de
+postar na lista de discussão. A instância do bot de build do patchwork fica
+sobrecarregada com muita facilidade e a netdev@vger realmente não precisa de
+mais tráfego se pudermos evitar.
+
+netdevsim
+~~~~~~~~~
+
+O ``netdevsim`` é um driver de teste que pode ser usado para exercitar APIs de
+configuração de driver sem a necessidade de hardware compatível. Mock-ups e
+testes baseados no ``netdevsim`` são fortemente encorajados ao adicionar novas
+APIs, mas o ``netdevsim`` em si **não** é considerado um caso de uso/usuário.
+Você também deve implementar as novas APIs em um driver real.
+
+Não damos garantias de que o ``netdevsim`` mudará no futuro de uma forma que
+quebraria o que normalmente seria considerado uAPI.  O ``netdevsim`` é reservado
+apenas para uso por testes upstream, portanto, quaisquer novos recursos do
+``netdevsim`` devem ser acompanhados de selftests em ``tools/testing/selftests/``.
+
+Status de suporte para drivers
+------------------------------
+
+.. note:
+
+Os requisitos a seguir aplicam-se apenas a drivers de NIC Ethernet.
+
+A netdev define requisitos adicionais para drivers que desejam adquirir o status
+``Supported`` (Suportado) no arquivo MAINTAINERS. Drivers ``Supported`` devem
+executar todos os testes de driver upstream e relatar os resultados duas vezes
+por dia. Drivers que não cumprirem este requisito devem usar o status
+``Maintained`` (Mantido). Atualmente, não há diferença na forma como os drivers
+``Supported`` e ``Maintained`` são tratados no upstream.
+
+As regras exatas que um driver deve seguir para adquirir o status ``Supported``:
+
+1. Deve executar todos os testes sob os alvos ``drivers/net`` e
+   ``drivers/net/hw`` dos selftests do Linux. A execução e o relato
+   de testes privados / internos também são bem-vindos, mas os testes
+   upstream são obrigatórios.
+
+2. A frequência mínima de execução é uma vez a cada 12 horas. Deve
+   testar o branch designado a partir do feed de branches selecionado.
+   Observe que os branches são construídos automaticamente e estão
+   expostos à postagem intencional de patches maliciosos; portanto,
+   os sistemas de teste devem ser isolados.
+
+3. Drivers que suportam múltiplas gerações de dispositivos devem
+   testar pelo menos um dispositivo de cada geração. Um manifesto do
+   ambiente de teste (*testbed manifest* - formato exato a definir)
+   deve descrever os modelos de dispositivos testados.
+
+4. Os testes devem ser executados de forma confiável; se múltiplos
+   branches forem ignorados ou se os testes falharem devido a problemas
+   no ambiente de execução, o status ``Supported`` será retirado.
+
+5. Falhas nos testes devido a bugs no driver ou no próprio teste,
+   ou falta de suporte para a funcionalidade que o teste visa, *não*
+   são motivo para a perda do status ``Supported``.
+
+O CI da netdev manterá uma página oficial de dispositivos suportados, listando
+seus resultados de testes recentes.
+
+O mantenedor do driver pode providenciar para que outra pessoa execute o teste;
+não há exigência de que a pessoa listada como mantenedora (ou seu empregador)
+seja responsável pela execução dos testes. Colaborações entre
+fornecedores, hospedagem de CI no GitHub (GH CI), outros repositórios sob o
+linux-netdev, etc., são muito bem-vindas.
+
+Veja https://github.com/linux-netdev/nipa/wiki para mais informações sobre o CI
+da netdev. Sinta-se à vontade para entrar em contato com os mantenedores ou com
+a lista para quaisquer dúvidas.
+
+Orientações para revisores
+--------------------------
+
+Revisar patches de outras pessoas na lista é altamente incentivado,
+independentemente do nível de experiência. Para orientações gerais e dicas
+úteis, consulte `revisão de tópicos avançados de desenvolvimento`.
+
+É seguro assumir que os mantenedores da netdev conhecem a comunidade e o nível
+de experiência dos revisores. Os revisores não devem se preocupar com o fato de
+seus comentários impedirem ou desviarem o fluxo de patches. Revisores menos
+experientes são fortemente incentivados a fazer uma revisão mais aprofundada das
+submissões e não focar exclusivamente em questões triviais ou subjetivas, como
+formatação de código, tags, etc.
+
+Depoimentos / feedback
+----------------------
+
+Algumas empresas utilizam o feedback de colegas em revisões de desempenho de
+funcionários. Sinta-se à vontade para solicitar feedback dos mantenedores da
+netdev, especialmente se você dedica uma quantidade significativa de tempo
+revisando código e se esforça além do esperado para melhorar a infraestrutura
+compartilhada.
+
+O feedback deve ser solicitado por você, o colaborador, e será sempre
+compartilhado com você (mesmo que você solicite que ele seja enviado ao seu
+gerente).

linux-7.2.3/Documentation/translations/pt_BR/process/maintainer-soc-clean-dts.rst

@@ -0,0 +1,28 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================================
+Plataformas SoC com Requisitos de Conformidade de DTS
+=====================================================
+
+Visão Geral
+-----------
+
+As plataformas SoC ou subarquiteturas devem seguir todas as regras de
+Documentation/process/maintainer-soc.rst. Este documento, referenciado em
+MAINTAINERS, impõe requisitos adicionais listados abaixo.
+
+Conformidade Estrita com DT Schema de DTS e dtc
+-----------------------------------------------
+
+Nenhuma alteração nos arquivos de origem do Devicetree da plataforma SoC
+(arquivos DTS) deve introduzir novos avisos de ``make dtbs_check W=1``.
+Avisos em um novo DTS de placa, que sejam resultado de problemas em um
+arquivo DTSI incluído, são considerados avisos existentes, não novos.
+Para séries divididas entre árvores diferentes (vínculos de DT seguem pela
+árvore do subsistema de drivers), os avisos no linux-next são decisivos.
+Os mantenedores da plataforma possuem automação implementada que deve
+apontar quaisquer novos avisos.
+
+Se um commit que introduz novos avisos for aceito de alguma forma, os
+problemas resultantes deverão ser corrigidos em um tempo razoável
+(por exemplo, dentro de um ciclo de lançamento) ou o commit será revertido.

linux-7.2.3/Documentation/translations/pt_BR/process/maintainer-soc.rst

@@ -0,0 +1,232 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============
+Subsistema SoC
+==============
+
+Visão Geral
+-----------
+
+O subsistema SoC é um local de agregação para códigos específicos de SoC
+(System on Chip). Os principais componentes do subsistema são:
+
+* Devicetrees (DTS) para ARM de 32 e 64 bits e RISC-V.
+* Arquivos de placa (board files) ARM de 32 bits (arch/arm/mach*).
+* Defconfigs ARM de 32 e 64 bits.
+* Drivers específicos de SoC em diversas arquiteturas, em particular para ARM de
+* 32 e 64 bits, RISC-V e Loongarch.
+
+Estes "drivers específicos de SoC" não incluem drivers de clock, GPIO, etc., que
+possuem outros mantenedores de alto nível. O diretório ``drivers/soc/`` é
+geralmente destinado a drivers internos do kernel que são usados por outros
+drivers para fornecer funcionalidades específicas do SoC, como identificar uma
+revisão do chip ou fazer a interface com domínios de energia.
+
+O subsistema SoC também serve como um local intermediário para alterações em
+``drivers/bus``, ``drivers/firmware``, ``drivers/reset`` e ``drivers/memory``.
+A adição de novas plataformas, ou a remoção de existentes, geralmente passa pela
+árvore SoC como um branch dedicado cobrindo múltiplos subsistemas.
+
+A árvore principal do SoC está hospedada no git.kernel.org:
+  https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/
+
+Mantenedores
+------------
+
+Claramente, esta é uma gama bastante ampla de tópicos, que nenhuma pessoa, ou
+mesmo um pequeno grupo de pessoas, é capaz de manter. Em vez disso, o
+subsistema SoC é composto por muitos submantenedores (mantenedores de
+plataforma), cada um cuidando de plataformas individuais e subdiretórios de
+drivers.
+
+Nesse sentido, "plataforma" geralmente se refere a uma série de SoCs de um
+determinado fornecedor, por exemplo, a série de SoCs Tegra da Nvidia. Muitos
+submantenedores operam em nível de fornecedor, sendo responsáveis por várias
+linhas de produtos. Por diversos motivos, incluindo aquisições ou diferentes
+unidades de negócios em uma empresa, as coisas variam significativamente aqui.
+Os diversos submantenedores estão documentados no arquivo ``MAINTAINERS``.
+
+A maioria desses submantenedores possui suas próprias árvores onde preparam os
+patches, enviando pull requests para a árvore SoC principal. Essas árvores são
+geralmente, mas nem sempre, listadas em ``MAINTAINERS``.
+
+O que a árvore SoC não é, contudo, é um local para alterações de código
+específicas da arquitetura. Cada arquitetura possui seus próprios mantenedores
+que são responsáveis pelos detalhes arquiteturais, erratas de CPU e afins.
+
+Submetendo Patches para um Determinado SoC
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Todos os patches típicos relacionados à plataforma devem ser enviados por meio
+dos submantenedores de SoC (mantenedores específicos da plataforma). Isso inclui
+também alterações em defconfigs por plataforma ou compartilhadas. Note que
+``scripts/get_maintainer.pl`` pode não fornecer os endereços corretos para a
+defconfig compartilhada; portanto, ignore sua saída e crie manualmente a lista
+de CC baseada no arquivo ``MAINTAINERS`` ou use algo como
+``scripts/get_maintainer.pl -f drivers/soc/FOO/``.
+
+Submetendo Patches para os Mantenedores Principais de SoC
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Os mantenedores principais de SoC podem ser contatados via o alias
+soc@kernel.org apenas nos seguintes casos:
+
+1. Não existem mantenedores específicos para a plataforma.
+
+2. Os mantenedores específicos da plataforma não respondem.
+
+3. Introdução de uma plataforma SoC completamente nova. Tal trabalho de novo SoC
+   deve ser enviado primeiro para as listas de discussão comuns, indicadas por
+   ``scripts/get_maintainer.pl``, para revisão da comunidade. Após uma revisão
+   positiva da comunidade, o trabalho deve ser enviado para soc@kernel.org em
+   um único conjunto de patches (*patchset*) contendo a nova entrada em
+   ``arch/foo/Kconfig``, arquivos DTS, entrada no arquivo ``MAINTAINERS`` e,
+   opcionalmente, drivers iniciais com seus respectivos bindings de Devicetree.
+   A entrada no arquivo ``MAINTAINERS`` deve listar os novos mantenedores
+   específicos da plataforma, que serão responsáveis por lidar com os patches
+   da plataforma de agora em diante.
+
+Note que o endereço soc@kernel.org geralmente não é o local para discutir os
+patches; portanto, o trabalho enviado para este endereço já deve ser
+considerado aceitável pela comunidade.
+
+Informações para (novos) Submantenedores
+----------------------------------------
+
+À medida que novas plataformas surgem, elas frequentemente trazem consigo novos
+submantenedores, muitos dos quais trabalham para o fornecedor do silício e podem
+não estar familiarizados com o processo.
+
+Estabilidade da ABI do Devicetree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Talvez um dos pontos mais importantes a destacar é que os *dt-bindings*
+documentam a ABI entre o devicetree e o kernel. Por favor, leia
+``Documentation/devicetree/bindings/ABI.rst``.
+
+Se estiverem sendo feitas alterações em um DTS que sejam incompatíveis com
+kernels antigos, o patch do DTS não deve ser aplicado até que o driver seja, ou
+em um momento apropriado posterior. Mais importante ainda, quaisquer alterações
+incompatíveis devem ser claramente apontadas na descrição do patch e no pull
+request, juntamente com o impacto esperado nos usuários existentes, como
+bootloaders ou outros sistemas operacionais.
+
+Dependências de Branch de Driver
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Um problema comum é a sincronização de alterações entre drivers de dispositivos
+e arquivos de devicetree. Mesmo que uma alteração seja compatível em ambas as
+direções, isso pode exigir a coordenação de como as mudanças são mescladas
+através de diferentes árvores de mantenedores.
+
+Geralmente, o branch que inclui uma alteração de driver também incluirá a
+mudança correspondente na descrição do binding do devicetree, para garantir que
+sejam, de fato, compatíveis. Isso significa que o branch do devicetree pode
+acabar causando avisos na etapa ``make dtbs_check``. Se uma alteração de
+devicetree depender de adições ausentes em um arquivo de cabeçalho em
+``include/dt-bindings/``, ela falhará na etapa ``make dtbs`` e não será mesclada.
+
+Existem várias maneiras de lidar com isso:
+
+* Evite definir macros personalizadas em ``include/dt-bindings/`` para constantes
+  de hardware que podem ser derivadas de um datasheet -- macros de binding em
+  arquivos de cabeçalho devem ser usadas apenas como último recurso, se não
+  houver uma maneira natural de definir um binding.
+
+* Use valores literais no arquivo devicetree em vez de macros, mesmo quando um
+  cabeçalho for necessário, e altere-os para a representação nomeada em um
+  lançamento posterior.
+
+* Adie as alterações do devicetree para um lançamento após o binding e o driver
+  já terem sido mesclados.
+
+* Altere os bindings em um branch imutável compartilhado que seja usado como
+  base tanto para a alteração do driver quanto para as alterações do devicetree.
+
+* Adicione definições duplicadas no arquivo devicetree protegidas por uma seção
+  ``#ifndef``, removendo-as em um lançamento posterior.
+
+Convenção de Nomenclatura de Devicetree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+O esquema geral de nomenclatura para arquivos de devicetree é o seguinte. Os
+aspectos de uma plataforma que são definidos no nível do SoC, como núcleos de
+CPU, são contidos em um arquivo nomeado ``$soc.dtsi``, por exemplo,
+``jh7100.dtsi``. Detalhes de integração, que variam de placa para placa, são
+descritos em ``$soc-$board.dts``. Um exemplo disso é
+``jh7100-beaglev-starlight.dts``. Frequentemente, muitas placas são variações
+de um mesmo tema, e é comum haver arquivos intermediários, como
+``jh7100-common.dtsi``, que ficam entre os arquivos ``$soc.dtsi`` e
+``$soc-$board.dts``, contendo as descrições de hardware comum.
+
+Algumas plataformas também possuem *System on Modules* (SoM), contendo um SoC,
+que são então integrados em diversas placas diferentes. Para essas plataformas,
+``$soc-$som.dtsi`` e ``$soc-$som-$board.dts`` são típicos.
+
+Os diretórios geralmente são nomeados após o fornecedor do SoC no momento de sua
+inclusão, o que leva a alguns nomes de diretórios históricos na árvore.
+
+Validando Arquivos de Devicetree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``make dtbs_check`` pode ser usado para validar se os arquivos de devicetree
+estão em conformidade com os *dt-bindings* que descrevem a ABI. Por favor, leia
+a seção "Running checks" de ``Documentation/devicetree/bindings/writing-schema.rst``
+para mais informações sobre a validação de devicetrees.
+
+Para novas plataformas, ou adições a plataformas existentes, ``make dtbs_check``
+não deve adicionar nenhum aviso (*warning*) novo. Para SoCs RISC-V e Samsung, é
+exigido que ``make dtbs_check W=1`` não adicione nenhum novo aviso.
+Se houver qualquer dúvida sobre uma alteração de devicetree, entre em contato
+com os mantenedores de devicetree.
+
+Branches e Pull Requests
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Assim como a árvore SoC principal possui vários branches, espera-se que os
+submantenedores façam o mesmo. Alterações de drivers, defconfig e devicetree
+devem ser todas divididas em branches separados e aparecer em pull requests
+distintos para os mantenedores de SoC. Cada branch deve ser utilizável por si só
+e evitar regressões originadas de dependências em outros branches.
+
+Pequenos conjuntos de patches também podem ser enviados como e-mails separados
+para soc@kernel.org, agrupados nas mesmas categorias.
+
+Se as alterações não se encaixarem nos padrões normais, pode haver branches de
+nível superior adicionais, por exemplo, para uma reformulação em toda a árvore
+(*treewide rework*) ou a adição de novas plataformas SoC, incluindo arquivos dts
+e drivers.
+
+Branches com muitas alterações podem se beneficiar ao serem divididos em
+branches de tópicos separados, mesmo que acabem sendo mesclados no mesmo branch
+da árvore SoC. Um exemplo aqui seria um branch para correções de avisos de
+devicetree, um para uma reformulação e um para placas recém-adicionadas.
+
+Outra forma comum de dividir as alterações é enviar um pull request antecipado
+com a maioria das mudanças em algum momento entre rc1 e rc4, seguido por um ou
+mais pull requests menores no final do ciclo, que podem adicionar alterações
+tardias ou resolver problemas identificados durante os testes do primeiro
+conjunto.
+
+Embora não haja um prazo limite para pull requests tardios, ajuda enviar apenas
+branches pequenos à medida que o tempo se aproxima da janela de mesclagem
+(*merge window*).
+
+Pull requests para correções de bugs (*bugfixes*) da versão atual podem ser
+enviados a qualquer momento, mas, novamente, ter múltiplos branches menores é
+melhor do que tentar combinar muitos patches em um único pull request.
+
+A linha de assunto de um pull request deve começar com "[GIT PULL]" e ser feita
+usando uma tag assinada, em vez de um branch. Esta tag deve conter uma breve
+descrição resumindo as alterações no pull request. Para mais detalhes sobre o
+envio de pull requests, consulte ``Documentation/maintainer/pull-requests.rst``.
+
+Propósito dos Defconfigs
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
+distribuições têm suas próprias configurações. Uma mudança que adiciona novas
+opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
+em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
+suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
+para máquinas não upstream não deve ser aceito.