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

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

File Facts

System
Linux kernel
Corpus path
Documentation/translations/sp_SP/process/3.Early-stage.rst
Extension
.rst
Size
12872 bytes
Lines
242
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

.. include:: ../disclaimer-sp.rst

:Original: Documentation/process/3.Early-stage.rst
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>

.. _sp_development_early_stage:

Planificación en etapa inicial
==============================

Cuando uno se sienta a planear un proyecto de desarrollo del kernel Linux,
puede ser tentador lanzarse directamente a escribir código. Sin embargo,
como ocurre con cualquier proyecto significativo, gran parte del trabajo
que conduce al éxito es mejor realizarlo antes de escribir la primera línea
de código. Dedicar tiempo a la planificación y comunicación temprana puede
ahorrar mucho más tiempo en adelante.

Especificar el problema
-----------------------

Como en cualquier proyecto de ingeniería, una mejora exitosa del kernel
comienza con una descripción clara del problema a resolver. En algunos
casos, este paso es sencillo: cuando se necesita un driver para un hardware
específico, por ejemplo. En otros, sin embargo, es tentador confundir el
problema real con la solución propuesta, lo que puede generar dificultades.

Consideremos un ejemplo: hace algunos años, los desarrolladores que
trabajaban con audio en Linux buscaban una forma de ejecutar aplicaciones
sin interrupciones u otros artefactos causados por la latencia excesiva en
el sistema. La solución a la que llegaron fue un módulo del kernel
destinado a integrarse en el marco del Módulo de Seguridad de Linux (LSM,
por sus siglas en inglés); este módulo podía configurarse para dar acceso a
aplicaciones específicas al planificador en tiempo real. Este módulo fue
implementado y enviado a la lista de correo del kernel de Linux, donde
inmediatamente encontró problemas.

Para los desarrolladores de audio, este módulo de seguridad era suficiente
para resolver su problema inmediato. Sin embargo, para la comunidad más
amplia del kernel, se veía como un uso indebido del marco LSM (que no está
diseñado para otorgar privilegios a procesos que de otro modo no los
tendrían) y como un riesgo para la estabilidad del sistema. Sus soluciones
preferidas implicaban el acceso a la programación en tiempo real a través
del mecanismo de rlimit a corto plazo, y trabajo continuo para reducir la
latencia a largo plazo.

La comunidad de audio, sin embargo, no podía ver más allá de la solución
particular que habían implementado; no estaban dispuestos a aceptar
alternativas. El desacuerdo resultante dejó a esos desarrolladores
desilusionados con todo el proceso de desarrollo del kernel; uno de ellos
volvió a una lista de audio y publicó esto (traducido):

	"Hay un buen número de desarrolladores muy competentes del kernel de Linux, pero tienden a ser opacados por una multitud de arrogantes necios. Intentar comunicar los requisitos de los usuarios a estas personas es una pérdida de tiempo. Son demasiado 'inteligentes' como para escuchar a simples mortales".

Siendo el texto original:

	There are a number of very good Linux kernel developers, but they
	tend to get outshouted by a large crowd of arrogant fools. Trying
	to communicate user requirements to these people is a waste of
	time. They are much too "intelligent" to listen to lesser mortals.

(https://lwn.net/Articles/131776/).

La realidad de la situación era diferente; los desarrolladores del kernel
estaban mucho más preocupados por la estabilidad del sistema, el
mantenimiento a largo plazo y encontrar la solución correcta al problema
que por un módulo específico. La moraleja de la historia es centrarse en el
problema, no en una solución específica, y discutirlo con la comunidad de
desarrollo antes de invertir en la creación de un cuerpo de código.

Por lo tanto, al contemplar un proyecto de desarrollo del kernel, se deben

Annotation

Implementation Notes