Spanish

Warning

Si tiene alguna duda sobre la exactitud del contenido de esta traducción, la única referencia válida es la documentación oficial en inglés. Además, por defecto, los enlaces a documentos redirigen a la documentación en inglés, incluso si existe una versión traducida. Consulte el índice para más información.

Original:

Documentation/process/3.Early-stage.rst

Translator:

Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>

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

3.1. 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 obtener respuestas a un conjunto corto de preguntas:

  • ¿Cuál es exactamente el problema que necesita ser resuelto?

  • ¿Quiénes son los usuarios afectados por este problema? ¿Qué casos de uso debería abordar la solución?

  • ¿En qué aspectos el kernel actual no logra abordar ese problema?

Solo entonces tiene sentido comenzar a considerar posibles soluciones.

3.2. Discusión temprana

Al planificar un proyecto de desarrollo del kernel, tiene mucho sentido realizar discusiones con la comunidad antes de lanzarse a la implementación. La comunicación temprana puede ahorrar tiempo y problemas de varias maneras:

  • Es posible que el problema ya esté siendo abordado por el kernel de maneras que no haya comprendido. El kernel de Linux es grande y tiene una serie de características y capacidades que no son inmediatamente obvias. No todas las capacidades del kernel están documentadas tan bien como uno quisiera, y es fácil pasar cosas por alto. El autor de este texto ha visto la publicación de un driver completo que duplicaba uno existente del que el nuevo autor no tenía conocimiento. El código que reinventa ruedas existentes no solo es desperdicio; tampoco será aceptado en el kernel principal.

  • Puede haber elementos de la solución propuesta que no serán aceptables para su inclusión en el kernel principal. Es mejor descubrir problemas como este antes de escribir el código.

  • Es completamente posible que otros desarrolladores ya hayan pensado en el problema; pueden tener ideas para una mejor solución y estar dispuestos a ayudar en la creación de esa solución.

Años de experiencia con la comunidad de desarrollo del kernel han enseñado una lección clara: el código del kernel que se diseña y desarrolla a puertas cerradas invariablemente tiene problemas que solo se revelan cuando el código se libera a la comunidad. A veces, estos problemas son graves, requiriendo meses o años de esfuerzo antes de que el código pueda cumplir con los estándares de la comunidad del kernel. Algunos ejemplos incluyen:

  • La pila de red Devicescape fue diseñada e implementada para sistemas de un solo procesador. No pudo fusionarse en la rama principal hasta que se hizo adecuada para sistemas multiprocesador. Adaptar el bloqueo y otros aspectos en el código es una tarea difícil; como resultado, la fusión de este código (ahora llamado mac80211) se retrasó más de un año.

  • El sistema de archivos Reiser4 incluía una serie de capacidades que, en opinión de los desarrolladores principales del kernel, deberían haberse implementado en la capa de sistemas de archivos virtuales. También incluía funciones que no podían implementarse fácilmente sin exponer el sistema a bloqueos causados por los usuarios. La revelación tardía de estos problemas, y la negativa a abordar algunos de ellos, ha mantenido a Reiser4 fuera del kernel principal.

  • El módulo de seguridad AppArmor hacía uso de estructuras de datos internas del sistema de archivos virtual de maneras que se consideraban inseguras y poco fiables. Esta preocupación (entre otras) mantuvo a AppArmor fuera de la rama principal durante años.

En cada uno de estos casos, se podría haber evitado mucho dolor y trabajo adicional con algunas discusiones tempranas con los desarrolladores del kernel.

3.3. ¿Con quién hablar?

Cuando los desarrolladores deciden hacer públicas sus ideas, la siguiente pregunta será: ¿dónde empezar? La respuesta es encontrar la lista de correo adecuada y el maintainer correcto. Para las listas de correo, la mejor opción es buscar en el archivo MAINTAINERS un lugar relevante para publicar. Si existe una lista de subsistema adecuada, es preferible publicarla allí en lugar de en linux-kernel; es más probable que llegues a desarrolladores con experiencia en el subsistema relevante y el ambiente puede ser más propicio.

Encontrar a los maintainers puede ser un poco más difícil. Nuevamente, el archivo MAINTAINERS es el lugar para empezar. Sin embargo, ese archivo tiende a no estar siempre actualizado, y no todos los subsistemas están representados allí. La persona listada en el archivo MAINTAINERS puede, de hecho, no ser la persona que está actuando en ese rol actualmente. Por lo tanto, cuando haya dudas sobre a quién contactar, un truco útil es usar git (y “git log” en particular) para ver quién está activo actualmente en el subsistema de interés. Mira quién está escribiendo parches y quién, si alguien, está adjuntando líneas de Signed-off-by a esos parches. Esas son las personas que estarán mejor posicionadas para ayudar con un nuevo proyecto de desarrollo.

La tarea de encontrar al maintainer correcto es lo suficientemente desafiante como para que los desarrolladores del kernel hayan añadido un script para facilitar el proceso:

.../scripts/get_maintainer.pl

Este script devolverá los maintainers actuales de un archivo o directorio dado cuando se le pase la opción “-f”. Si se le pasa un parche en la línea de comandos, listará a los maintainers que probablemente deberían recibir copias del parche. Esta es la manera preferida (a diferencia de la opción “-f”) de obtener la lista de personas a las que hay que enviar las copias de sus parches. Hay varias opciones que regulan cuán agresivamente get_maintainer.pl buscará maintainers; por favor, ten cuidado al usar las opciones más agresivas, ya que podrías terminar incluyendo desarrolladores que no tienen ningún interés real en el código que estás modificando.

Si todo lo demás falla, hablar con Andrew Morton puede ser una forma efectiva de encontrar a un maintainer para un código específico.

3.4. ¿Cuándo publicar?

Si es posible, publicar sus planes en las primeras etapas solo puede ser útil. Describa el problema que se está resolviendo y cualquier plan que se haya hecho sobre cómo se llevará a cabo la implementación. Cualquier información que puedas proporcionar puede ayudar a la comunidad de desarrollo a ofrecer comentarios útiles sobre el proyecto.

Una cosa desalentadora que puede suceder en esta etapa no es una reacción hostil, sino, en cambio, poca o ninguna reacción en absoluto. La triste realidad es que (1) los desarrolladores del kernel tienden a estar ocupados, (2) no hay escasez de personas con grandes planes y poco código (o incluso perspectivas de código) para respaldarlos, y (3) nadie está obligado a revisar o comentar las ideas publicadas por otros. Además, los diseños de alto nivel a menudo esconden problemas que solo se revelan cuando alguien realmente intenta implementar esos diseños; por esa razón, los desarrolladores del kernel prefieren ver el código.

Si una publicación de solicitud de comentarios genera pocos comentarios, no asuma que significa que no hay interés en el proyecto. Desafortunadamente, tampoco puedes asumir que no hay problemas con tu idea. Lo mejor que puede hacer en esta situación es seguir adelante, manteniendo informada a comunidad a medida que avanza.

3.5. Obtener respaldo oficial

Si su trabajo se está realizando en un entorno corporativo — como ocurre con la mayoría del trabajo en el kernel de Linux — es obvio que debe tener permiso de los jefes debidamente autorizados antes de poder publicar los planes o el código de su empresa en una lista de correo pública. La publicación de código que no ha sido autorizado para su liberación bajo una licencia compatible con la GPL puede ser especialmente problemática; cuanto antes la gerencia y el personal legal de una empresa lleguen a un acuerdo sobre la publicación de un proyecto de desarrollo del kernel, mejor será para todos los involucrados.

Algunos lectores pueden estar pensando en este momento que su trabajo en el kernel está destinado a respaldar un producto que aún no ha sido reconocido oficialmente. Revelar los planes de su empleador en una lista de correo pública puede no ser una opción viable. En casos como este, vale la pena considerar si realmente es necesario mantener el secreto; a menudo no hay una necesidad real de mantener los planes de desarrollo en secreto.

Dicho esto, también hay casos en los que una empresa legítimamente no puede revelar sus planes al inicio del proceso de desarrollo. Las empresas con desarrolladores experimentados en el kernel pueden optar por proceder de manera abierta, bajo el supuesto de que podrán evitar problemas graves de integración más adelante. Para las empresas sin ese tipo de experiencia interna, la mejor opción suele ser contratar a un desarrollador externo para que revise los planes bajo un acuerdo de confidencialidad (NDA). La Linux Foundation opera un programa de NDA diseñado para ayudar en este tipo de situaciones; se puede encontrar más información en:

Este tipo de revisión suele ser suficiente para evitar problemas graves más adelante sin necesidad de revelar públicamente el proyecto.