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

Source file repositories/reference/linux-study-clean/Documentation/translations/pt_BR/process/3.Early-stage.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/pt_BR/process/3.Early-stage.rst
Extension
.rst
Size
12726 bytes
Lines
234
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

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

Annotation

Implementation Notes