.. 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.
