3. 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.
3.1. 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.
3.2. 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.
3.3. 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.
3.4. 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.
3.5. 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:
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.