[PATCH 0/2] Documentation: Start Spanish translation and include HOWTO

[PATCH 0/2] Documentation: Start Spanish translation and include HOWTO

[Carlos Bilbao]

Spanish is the second most spoken language in the world. This patch set
starts the process of translating critical kernel documentation into the
Spanish language.

Carlos Bilbao (2):
  Documentation: Start translations to Spanish
  Documentation: Add HOWTO Spanish translation into rst based build system

 Documentation/translations/index.rst          |   1 +
 .../translations/sp_SP/disclaimer-sp.rst      |   6 +
 Documentation/translations/sp_SP/howto.rst    | 619 ++++++++++++++++++
 Documentation/translations/sp_SP/index.rst    |  80 +++
 4 files changed, 706 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
 create mode 100644 Documentation/translations/sp_SP/howto.rst
 create mode 100644 Documentation/translations/sp_SP/index.rst

[PATCH 1/2] Documentation: Start translations to Spanish

[Carlos Bilbao]

Start the process of translating kernel documentation to Spanish. Create
sp_SP/ and include an index and a disclaimer, following the approach of
prior translations.

Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
---
 Documentation/translations/index.rst          |  1 +
 .../translations/sp_SP/disclaimer-sp.rst      |  6 ++
 Documentation/translations/sp_SP/index.rst    | 73 +++++++++++++++++++
 3 files changed, 80 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
 create mode 100644 Documentation/translations/sp_SP/index.rst

diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst
index 1175a47d07f0..b826c34791c0 100644
--- a/Documentation/translations/index.rst
+++ b/Documentation/translations/index.rst
@@ -12,6 +12,7 @@ Translations
    it_IT/index
    ko_KR/index
    ja_JP/index
+   sp_SP/index


 .. _translations_disclaimer:
diff --git a/Documentation/translations/sp_SP/disclaimer-sp.rst b/Documentation/translations/sp_SP/disclaimer-sp.rst
new file mode 100644
index 000000000000..a400034e95f9
--- /dev/null
+++ b/Documentation/translations/sp_SP/disclaimer-sp.rst
@@ -0,0 +1,6 @@
+:orphan:
+
+.. 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.
diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst
new file mode 100644
index 000000000000..bf6a24a2399d
--- /dev/null
+++ b/Documentation/translations/sp_SP/index.rst
@@ -0,0 +1,73 @@
+.. _sp_linux_doc:
+
+=======================
+Traducción al español
+=======================
+
+.. raw:: latex
+
+	\kerneldocCJKoff
+
+:maintainer: Carlos Bilbao <carlos.bilbao@amd.com>
+
+.. _sp_disclaimer:
+
+Advertencia
+===========
+
+El objetivo de esta traducción es facilitar la lectura y comprensión para
+aquellos que no entiendan inglés o duden de sus interpretaciones, o
+simplemente para aquellos que prefieran leer en el idioma español. Sin
+embargo, tenga en cuenta que la *única* documentación oficial es la que
+está en inglés: :ref:`linux_doc`
+
+La propagación simultanea de la traducción de una modificación en
+:ref:`linux_doc` es altamente improbable. Los maintainers y colaboradores
+de la traducción intentan mantener sus traducciones al día, en tanto les
+es posible. Por tanto, no existe ninguna garantía de que una traducción
+esté actualizada con las ultimas modificaciones. Si lo que lee en una
+traducción no se corresponde con lo que ve en el código fuente, informe
+al maintainer de la traducción y, si puede, consulte la documentación en
+inglés.
+
+Una traducción no es una * bifurcación * de la documentación oficial, por
+lo que los usuarios no encontrarán aquí ninguna información que no sea la
+versión oficial. Cualquier adición, supresión o modificación de los
+contenidos deberá ser realizada anteriormente en los documentos en inglés.
+Posteriormente, y cuando sea posible, dicho cambio debería aplicarse
+también a las traducciones. Los maintainers de las traducciones aceptan
+contribuciones que son puramente de interés relativo a la traducción (por
+ejemplo, nuevas traducciones, actualizaciones, correcciones).
+
+Las traducciones tratan de ser lo más precisas posible pero no es posible
+convertir directamente un idioma a otro. Cada idioma tiene su propia
+gramática, y una cultura tras ella, por lo tanto, la traducción de una
+oración al inglés se podría modificar para adaptarlo al español. Por esta
+razón, cuando lea esta traducción, puede encontrar algunas diferencias en
+la forma, pero todavía transmiten el mensaje original. A pesar de la gran
+difusión del inglés en el idioma hablado, cuando sea posible, estos será
+reemplazado por las palabras correspondientes en español.
+
+Si necesita ayuda para comunicarse con la comunidad de Linux pero no se
+siente cómodo escribiendo en inglés, puede pedir ayuda al maintainer para
+obtener una traducción.
+
+Muchos países hablan español, cada uno con su propia cultura, expresiones,
+y diferencias gramaticales en ocasiones significativas. Las traducciones de
+los maintainers pueden utilizar el español con el que dichos maintainers se
+sientan mas cómodos. En principio, estas pequeñas diferencias no deberían
+suponer una gran barrera para hablantes de distintas versiones del español,
+pero en caso de duda se puede consultar a los maintainers.
+
+La documentación del kernel de Linux
+====================================
+
+Este es el nivel superior de la documentación del kernel en idioma español.
+La traducción es incompleta, y podría encontrar advertencias que indiquen
+la falta de una traducción o de un grupo de traducciones.
+
+En términos más generales, la documentación, como el kernel mismo, están en
+constante desarrollo. Las mejoras en la documentación siempre son
+bienvenidas; de modo que, si desea ayudar, únase a la lista de correo de
+linux-doc en vger.kernel.org.
+
--
2.34.1

[PATCH 2/2] Documentation: Add HOWTO Spanish translation into rst based build system

[Carlos Bilbao]

This commit adds Spanish translation of HOWTO document into rst based
documentation build system.

Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
---
 Documentation/translations/sp_SP/howto.rst | 619 +++++++++++++++++++++
 Documentation/translations/sp_SP/index.rst |   7 +
 2 files changed, 626 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/howto.rst

diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
new file mode 100644
index 000000000000..4cf8fa6b9f7c
--- /dev/null
+++ b/Documentation/translations/sp_SP/howto.rst
@@ -0,0 +1,619 @@
+.. include:: ./disclaimer-sp.rst
+
+:Original: :ref:`Documentation/process/howto.rst <process_howto>`
+:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
+
+.. _sp_process_howto:
+
+Cómo participar en el desarrollo del kernel de Linux
+====================================================
+
+Este documento es el principal punto de partida. Contiene instrucciones
+sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
+trabajar con el y en su desarrollo. El documento no tratará ningún aspecto
+técnico relacionado con la programación del kernel, pero le ayudará
+guiándole por el camino correcto.
+
+Si algo en este documento quedara obsoleto, envíe parches al maintainer de
+este archivo, que se encuentra en la parte superior del documento.
+
+Introducción
+------------
+¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
+kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
+Linux para este dispositivo." El objetivo de este documento en enseñarle
+todo cuanto necesita para conseguir esto, describiendo el proceso por el
+que debe pasar, y con indicaciones de como trabajar con la comunidad.
+También trata de explicar las razones por las cuales la comunidad trabaja
+de la forma en que lo hace.
+
+El kernel esta principalmente escrito en C, con algunas partes que son
+dependientes de la arquitectura en ensamblador. Un buen conocimiento de C
+es necesario para desarrollar en el kernel. Lenguaje ensamblador (en
+cualquier arquitectura) no es necesario excepto que planee realizar
+desarrollo de bajo nivel para dicha arquitectura. Aunque no es un perfecto
+sustituto para una educación sólida en C y/o años de experiencia, los
+siguientes libros sirven, como mínimo, como referencia:
+
+- "The C Programming Language" de Kernighan e Ritchie [Prentice Hall]
+- "Practical C Programming" de Steve Oualline [O'Reilly]
+- "C:  A Reference Manual" de Harbison and Steele [Prentice Hall]
+
+El kernel está escrito usando GNU C y la cadena de herramientas GNU. Si
+bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que
+no aparecen en dicho estándar. El kernel usa un C independiente de entorno,
+sin depender de la biblioteca C estándar, por lo que algunas partes del
+estándar C no son compatibles. Divisiones de long long arbitrarios o
+de coma flotante no son permitidas. En ocasiones, puede ser difícil de
+entender las suposiciones que el kernel hace respecto a la cadena de
+herramientas y las extensiones que usa, y desafortunadamente no hay
+referencia definitiva para estos. Consulte las páginas de información de
+gcc (`info gcc`) para obtener información al respecto.
+
+Recuerde que está tratando de aprender a trabajar con una comunidad de
+desarrollo existente. Es un grupo diverso de personas, con altos estándares
+de codificación, estilo y procedimiento. Estas normas han sido creadas a lo
+largo del tiempo en función de lo que se ha encontrado que funciona mejor
+para un equipo tan grande y geográficamente disperso. Trate de aprender
+tanto como le sea posible acerca de estos estándares antes de tiempo, ya
+que están bien documentados; no espere que la gente se adapte a usted o a
+su forma de ser de hacer las cosas.
+
+Cuestiones legales
+------------------
+El código fuente del kernel de Linux se publica bajo licencia GPL. Por
+favor, revise el archivo COPYING, presente en la carpeta principal del
+fuente, para detalles de la licencia. Si tiene alguna otra pregunta
+sobre licencias, contacte a un abogado, no pregunte en listas de discusión
+del kernel de Linux. Las personas en estas listas no son abogadas, y no
+debe confiar en sus opiniones en materia legal.
+
+Para preguntas y respuestas más frecuentes sobre la licencia GPL, consulte:
+
+	https://www.gnu.org/licenses/gpl-faq.html
+
+Documentacion
+--------------
+El código fuente del kernel de Linux tiene una gran variedad de documentos
+que son increíblemente valiosos para aprender a interactuar con la
+comunidad del kernel. Cuando se agregan nuevas funciones al kernel, se
+recomienda que se incluyan nuevos archivos de documentación que expliquen
+cómo usar la función. Cuando un cambio en el kernel hace que la interfaz
+que el kernel expone espacio de usuario cambie, se recomienda que envíe la
+información o un parche en las páginas del manual que expliquen el cambio
+a mtk.manpages@gmail.com, y CC la lista linux-api@vger.kernel.org.
+
+Esta es la lista de archivos que están en el código fuente del kernel y son
+de obligada lectura:
+
+  :ref:`Documentation/admin-guide/README.rst <readme>`
+    Este archivo ofrece una breve descripción del kernel de Linux y
+    describe lo que es necesario hacer para configurar y compilar el
+    kernel. Quienes sean nuevos en el kernel deben comenzar aquí.
+
+  :ref:`Documentation/process/changes.rst <changes>`
+    Este archivo proporciona una lista de los niveles mínimos de varios
+    paquetes que son necesarios para construir y ejecutar el kernel
+    exitosamente.
+
+  :ref:`Documentation/process/coding-style.rst <codingstyle>`
+    Esto describe el estilo de código del kernel de Linux y algunas de los
+    razones detrás de esto. Se espera que todo el código nuevo siga las
+    directrices de este documento. La mayoría de los maintainers solo
+    aceptarán parches si se siguen estas reglas, y muchas personas solo
+    revisan el código si tiene el estilo adecuado.
+
+  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+    Este archivo describe en gran detalle cómo crear con éxito y enviar un
+    parche, que incluye (pero no se limita a):
+
+       - Contenidos del correo electrónico (email)
+       - Formato del email
+       - A quien se debe enviar
+
+    Seguir estas reglas no garantiza el éxito (ya que todos los parches son
+    sujetos a escrutinio de contenido y estilo), pero en caso de no seguir
+    dichas reglas, el fracaso es prácticamente garantizado.
+    Otras excelentes descripciones de cómo crear parches correctamente son:
+
+	"The Perfect Patch"
+		https://www.ozlabs.org/~akpm/stuff/tpp.txt
+
+	"Linux kernel patch submission format"
+		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
+
+  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
+    Este archivo describe la lógica detrás de la decisión consciente de
+    no tener una API estable dentro del kernel, incluidas cosas como:
+
+      - Capas intermedias del subsistema (por compatibilidad?)
+      - Portabilidad de drivers entre sistemas operativos
+      - Mitigar el cambio rápido dentro del árbol de fuentes del kernel (o
+        prevenir cambios rápidos)
+
+     Este documento es crucial para comprender la filosofía del desarrollo
+     de Linux y es muy importante para las personas que se mudan a Linux
+     tras desarrollar otros sistemas operativos.
+
+  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
+    Si cree que ha encontrado un problema de seguridad en el kernel de
+    Linux, siga los pasos de este documento para ayudar a notificar a los
+    desarrolladores del kernel y ayudar a resolver el problema.
+
+  :ref:`Documentation/process/management-style.rst <managementstyle>`
+    Este documento describe cómo operan los maintainers del kernel de Linux
+    y los valores compartidos detrás de sus metodologías. Esta es una
+    lectura importante para cualquier persona nueva en el desarrollo del
+    kernel (o cualquier persona que simplemente sienta curiosidad por
+    el campo IT), ya que clarifica muchos conceptos erróneos y confusiones
+    comunes sobre el comportamiento único de los maintainers del kernel.
+
+  :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+    Este archivo describe las reglas sobre cómo se suceden las versiones
+    del kernel estable, y qué hacer si desea obtener un cambio en una de
+    estas publicaciones.
+
+  :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
+    Una lista de documentación externa relativa al desarrollo del kernel.
+    Por favor consulte esta lista si no encuentra lo que están buscando
+    dentro de la documentación del kernel.
+
+  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
+    Una buena introducción que describe exactamente qué es un parche y cómo
+    aplicarlo a las diferentes ramas de desarrollo del kernel.
+
+El kernel también tiene una gran cantidad de documentos que pueden ser
+generados automáticamente desde el propio código fuente o desde
+ReStructuredText markups (ReST), como este. Esto incluye un descripción
+completa de la API en el kernel y reglas sobre cómo manejar cerrojos
+(locking) correctamente.
+
+Todos estos documentos se pueden generar como PDF o HTML ejecutando::
+
+	make pdfdocs
+	make htmldocs
+
+respectivamente desde el directorio fuente principal del kernel.
+
+Los documentos que utilizan el markup ReST se generarán en
+Documentation/output. También se pueden generar en formatos LaTeX y ePub
+con::
+
+	make latexdocs
+	make epubdocs
+
+Convertirse en un/a desarrollador/a de kernel
+-------------------------------------------
+
+Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
+el proyecto Linux KernelNewbies:
+
+	https://kernelnewbies.org
+
+Consiste en una útil lista de correo donde puede preguntar casi cualquier
+tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en
+los archivos primero, antes de preguntar algo que ya ha sido respondido en
+el pasado.) También tiene un canal IRC que puede usar para hacer preguntas
+en en tiempo real, y una gran cantidad de documentación útil que es útil
+para ir aprendiendo sobre el desarrollo del kernel de Linux.
+
+El sitio web tiene información básica sobre la organización del código,
+subsistemas, y proyectos actuales (tanto dentro como fuera del árbol).
+También describe alguna información logística básica, como cómo compilar
+un kernel y aplicar un parche.
+
+Si no sabe por dónde quiere empezar, pero quieres buscar alguna tarea que
+comenzar a hacer para unirse a la comunidad de desarrollo del kernel,
+acuda al proyecto Linux Kernel Janitor:
+
+	https://kernelnewbies.org/KernelJanitors
+
+Es un gran lugar para comenzar. Describe una lista de problemas
+relativamente simples que deben limpiarse y corregirse dentro del codigo
+fuente del kernel de Linux árbol de fuentes. Trabajando con los
+desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos
+para incluir su parche en el árbol del kernel de Linux, y posiblemente
+descubrir en la dirección en que trabajar a continuación, si no tiene ya
+una idea.
+
+Antes de realizar cualquier modificación real al código del kernel de
+Linux, es imperativo entender cómo funciona el código en cuestión. Para
+este propósito, nada es mejor que leerlo directamente (lo más complicado
+está bien comentado), tal vez incluso con la ayuda de herramientas
+especializadas. Una de esas herramientas que se recomienda especialmente
+es el proyecto Linux Cross-Reference, que es capaz de presentar el código
+fuente en un formato de página web indexada y autorreferencial. Una
+excelente puesta al día del repositorio del código del kernel se puede
+encontrar en:
+
+	https://elixir.bootlin.com/
+
+El proceso de desarrollo
+------------------------
+
+El proceso de desarrollo del kernel de Linux consiste actualmente de
+diferentes "branches" (ramas) con muchos distintos subsistemas específicos
+a cada una de ellas. Las diferentes ramas son:
+
+  - El código principal de Linus (mainline tree)
+  - Varios árboles estables con múltiples major numbers
+  - Subsistemas específicos
+  - linux-next, para integración y testing
+
+Mainline tree (Árbol principal)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en
+https://kernel.org o en su repo.  El proceso de desarrollo es el siguiente:
+
+  - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos
+    semanas, durante este período de tiempo, los maintainers pueden enviar
+    grandes modificaciones a Linus, por lo general los parches que ya se
+    han incluido en el linux-next durante unas semanas. La forma preferida
+    de enviar grandes cambios es usando git (la herramienta de
+    administración de codigo fuente del kernel, más información al respecto
+    en https://git-scm.com/), pero los parches simples también son validos.
+  - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra
+    en hacer que el kernel nuevo lo más estable ("solido") posible. La
+    mayoría de los parches en este punto debe arreglar una regresión. Los
+    errores que siempre han existido no son regresiones, por lo tanto, solo
+    envíe este tipo de correcciones si son importantes. Tenga en cuenta que
+    se podría aceptar un controlador (o sistema de archivos) completamente
+    nuevo después de -rc1 porque no hay riesgo de causar regresiones con
+    tal cambio, siempre y cuando el cambio sea autónomo y no afecte áreas
+    fuera del código que se está agregando. git se puede usar para enviar
+    parches a Linus después de que se lance -rc1, pero los parches también
+    deben ser enviado a una lista de correo pública para su revisión.
+  - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git
+    actual esta en un estado razonablemente sano y adecuado para la prueba.
+    La meta es lanzar un nuevo kernel -rc cada semana.
+  - El proceso continúa hasta que el kernel se considera "listo", y esto
+    puede durar alrededor de 6 semanas.
+
+Vale la pena mencionar lo que Andrew Morton escribió en las listas de
+correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
+
+	*"Nadie sabe cuándo se publicara un nuevo kernel, porque esto sucede
+    de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
+    una línea temporal preconcebida."*
+
+Varios árboles estables con múltiples major numbers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Los kernels con versiones de 3 partes son kernels estables. Estos contienen
+correcciones relativamente pequeñas y críticas para problemas de seguridad
+o importantes regresiones descubiertas para una publicación de código.
+Cada lanzamiento en una gran serie estable incrementa la tercera parte de
+la versión número, manteniendo las dos primeras partes iguales.
+
+Esta es la rama recomendada para los usuarios que quieren la versión
+estable más reciente del kernel, y no están interesados ​​en ayudar a probar
+versiones en desarrollo/experimentales.
+
+Los árboles estables son mantenidos por el equipo "estable"
+<stable@vger.kernel.org>, y se liberan (publican) según lo dicten las
+necesidades. El período de liberación normal es de aproximadamente dos
+semanas, pero puede ser más largo si no hay problemas apremiantes. Un
+problema relacionado con la seguridad, en cambio, puede causar un
+lanzamiento casi instantáneamente.
+
+El archivo :ref:`Documentación/proceso/stable-kernel-rules.rst <stable_kernel_rules>`
+en el árbol del kernel documenta qué tipos de cambios son aceptables para
+el árbol estable y cómo funciona el proceso de lanzamiento.
+
+Subsistemas específicos
+~~~~~~~~~~~~~~~~~~~~~~~~
+Los maintainers de los diversos subsistemas del kernel --- y también muchos
+desarrolladores de subsistemas del kernel --- exponen su estado actual de
+desarrollo en repositorios fuente. De esta manera, otros pueden ver lo que
+está sucediendo en las diferentes áreas del kernel. En áreas donde el
+desarrollo es rápido, se le puede pedir a un desarrollador que base sus
+envíos en tal árbol del subsistema del kernel, para evitar conflictos entre
+este y otros trabajos ya en curso.
+
+La mayoría de estos repositorios son árboles git, pero también hay otros
+SCM en uso, o colas de parches que se publican como series quilt. Las
+direcciones de estos repositorios de subsistemas se enumeran en el archivo
+MAINTAINERS. Muchos de estos se pueden ver en https://git.kernel.org/.
+
+Antes de que un parche propuesto se incluya con dicho árbol de subsistemas,
+es sujeto a revisión, que ocurre principalmente en las listas de correo
+(ver la sección respectiva a continuación). Para varios subsistemas del
+kernel, esta revisión se rastrea con la herramienta patchwork. Patchwork
+ofrece una interfaz web que muestra publicaciones de parches, cualquier
+comentario sobre un parche o revisiones a él, y los maintainers pueden
+marcar los parches como en revisión, aceptado, o rechazado. La mayoría de
+estos sitios de trabajo de parches se enumeran en
+
+https://patchwork.kernel.org/.
+
+linux-next, para integración y testing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Antes de que las actualizaciones de los árboles de subsistemas se combinen
+con el árbol principal, necesitan probar su integración. Para ello, existe
+un repositorio especial de pruebas en el que se encuentran casi todos los
+árboles de subsistema, actualizado casi a diario:
+
+	https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
+
+De esta manera, linux-next ofrece una perspectiva resumida de lo que se
+espera que entre en el kernel principal en el próximo período de "merge"
+(fusión de codigo). Los testers aventureros son bienvenidos a probar
+linux-next en ejecución.
+
+Reportar bugs
+-------------
+
+El archivo 'Documentación/admin-guide/reporting-issues.rst' en el
+directorio principal del kernel describe cómo informar un posible bug del
+kernel y detalles sobre qué tipo de información necesitan los
+desarrolladores del kernel para ayudar a rastrear la fuente del problema.
+
+Gestión de informes de bugs
+------------------------------
+
+Una de las mejores formas de poner en práctica sus habilidades de hacking
+es arreglando errores reportados por otras personas. No solo ayudará a
+hacer el kernel más estable, también aprenderá a solucionar problemas del
+mundo real y mejora sus habilidades, y otros desarrolladores se darán
+cuenta de tu presencia. La corrección de errores es una de las mejores
+formas de ganar méritos entre desarrolladores, porque no a muchas personas
+les gusta perder el tiempo arreglando los errores de otras personas.
+
+Para trabajar en informes de errores ya reportados, busque un subsistema
+que le interese. Verifique el archivo MAINTAINERS donde se informan los
+errores de ese subsistema; con frecuencia será una lista de correo, rara
+vez un rastreador de errores (bugtracker). Busque en los archivos de dicho
+lugar para informes recientes y ayude donde lo crea conveniente. También es
+posible que desee revisar https://bugzilla.kernel.org para informes de
+errores; solo un puñado de subsistemas del kernel lo emplean activamente
+para informar o rastrear; sin embargo, todos los errores para todo el kernel
+se archivan allí.
+
+Listas de correo
+-----------------
+
+Como se explica en algunos de los documentos anteriores, la mayoría de
+desarrolladores del kernel participan en la lista de correo del kernel de
+Linux. Detalles sobre cómo para suscribirse y darse de baja de la lista se
+pueden encontrar en:
+
+	http://vger.kernel.org/vger-lists.html#linux-kernel
+
+Existen archivos de la lista de correo en la web en muchos lugares
+distintos. Utilice un motor de búsqueda para encontrar estos archivos. Por
+ejemplo:
+
+	http://dir.gmane.org/gmane.linux.kernel
+
+Es muy recomendable que busque en los archivos sobre el tema que desea
+tratar, antes de publicarlo en la lista. Un montón de cosas ya discutidas
+en detalle solo se registran en los archivos de la lista de correo.
+
+La mayoría de los subsistemas individuales del kernel también tienen sus
+propias lista de correo donde hacen sus esfuerzos de desarrollo. Revise el
+archivo MAINTAINERS para obtener referencias de lo que estas listas para
+los diferentes grupos.
+
+Muchas de las listas están alojadas en kernel.org. La información sobre
+estas puede ser encontrada en:
+
+	http://vger.kernel.org/vger-lists.html
+
+Recuerde mantener buenos hábitos de comportamiento al usar las listas.
+Aunque un poco cursi, la siguiente URL tiene algunas pautas simples para
+interactuar con la lista (o cualquier lista):
+
+	http://www.albion.com/netiquette/
+
+Si varias personas responden a su correo, el CC (lista de destinatarios)
+puede hacerse bastante grande. No elimine a nadie de la lista CC: sin una
+buena razón, o no responda solo a la dirección de la lista. Acostúmbrese
+a recibir correos dos veces, una del remitente y otra de la lista, y no
+intente ajustar esto agregando encabezados de correo astutos, a la gente no
+le gustará.
+
+Recuerde mantener intacto el contexto y la atribución de sus respuestas,
+mantenga las líneas "El hacker John Kernel escribió ...:" en la parte
+superior de su respuesta, y agregue sus declaraciones entre las secciones
+individuales citadas en lugar de escribiendo en la parte superior del
+correo electrónico.
+
+Si incluye parches en su correo, asegúrese de que sean texto legible sin
+formato como se indica en :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
+Los desarrolladores del kernel no quieren lidiar con archivos adjuntos o
+parches comprimidos; y pueden querer comentar líneas individuales de su
+parche, que funciona sólo de esa manera. Asegúrese de emplear un programa
+de correo que no altere los espacios ni los tabuladores. Una buena primera
+prueba es enviarse el correo a usted mismo, e intentar aplicar su
+propio parche. Si eso no funciona, arregle su programa de correo o
+reemplace hasta que funcione.
+
+Sobretodo, recuerde de ser respetuoso con otros subscriptores.
+
+Colaborando con la comunidad
+----------------------------
+
+El objetivo de la comunidad del kernel es proporcionar el mejor kernel
+posible. Cuando envíe un parche para su aceptación, se revisará en sus
+méritos técnicos solamente. Entonces, ¿qué deberías ser?
+
+  - criticas
+  - comentarios
+  - peticiones de cambios
+  - peticiones de justificaciones
+  - silencio
+
+Recuerde, esto es parte de introducir su parche en el kernel. Tiene que ser
+capaz de recibir críticas y comentarios sobre sus parches, evaluar
+a nivel técnico y re-elaborar sus parches o proporcionar razonamiento claro
+y conciso de por qué no se deben hacer tales cambios. Si no hay respuestas
+a su publicación, espere unos días e intente de nuevo, a veces las cosas se
+pierden dado el gran volumen.
+
+¿Qué no debería hacer?
+
+  - esperar ue su parche se acepte sin preguntas
+  - actuar de forma defensiva
+  - ignorar comentarios
+  - enviar el parche de nuevo, sin haber aplicados los cambios pertinentes
+
+En una comunidad que busca la mejor solución técnica posible, siempre habrá
+diferentes opiniones sobre lo beneficioso que es un parche. Tiene que ser
+cooperativo y estar dispuesto a adaptar su idea para que encaje dentro
+del kernel, o al menos esté dispuesto a demostrar que su idea vale la pena.
+Recuerea, estar equivocado es aceptable siempre y cuando estés dispuesto a
+trabajar hacia una solución que sea correcta.
+
+Es normal que las respuestas a su primer parche sean simplemente una lista
+de una docena de cosas que debe corregir. Esto **no** implica que su
+parche no será aceptado, y **no** es personal. Simplemente corrija todos
+los problemas planteados en su parche, y envié otra vez.
+
+Diferencias entre la comunidad kernel y las estructuras corporativas
+--------------------------------------------------------------------
+
+La comunidad del kernel funciona de manera diferente a la mayoría de los
+entornos de desarrollo tradicionales en empresas. Aquí hay una lista de
+cosas que puede intentar hacer para evitar problemas:
+
+  Cosas buenas que decir respecto a los cambios propuestos:
+
+    - "Esto arregla múltiples problemas."
+    - "Esto elimina 2000 lineas de código."
+    - "Aquí hay un parche que explica lo que intento describir."
+    - "Lo he testeado en 5 arquitecturas distintas..."
+    - "Aquí hay una serie de parches menores que..."
+    - "Esto mejora el rendimiento en maquinas típicas..."
+
+  Cosas negativas que debe evitar decir:
+
+    - "Lo hicimos asi en AIX/ptx/Solaris, de modo que debe ser bueno..."
+    - "LLevo haciendo esto 20 años, de modo que..."
+    - "Esto lo necesita mi empresa para ganar dinero"
+    - "Esto es para la linea de nuestros productos Enterprise"
+    - "Aquí esta el documento de 1000 paginas describiendo mi idea"
+    - "Llevo 6 meses trabajando en esto..."
+    - "Aquí esta un parche de 5000 lineas que..."
+    - "He rescrito todo el desastre actual, y aqui esta..."
+    - "Tengo un deadline, y este parche debe aplicarse ahora."
+
+Otra forma en que la comunidad del kernel es diferente a la mayoría de los
+entornos de trabajo tradicionales en ingeniería de software, es la
+naturaleza sin rostro de interacción. Una de las ventajas de utilizar el
+correo electrónico y el IRC como formas principales de comunicación es la
+no discriminación por motivos de género o raza. El entorno de trabajo del
+kernel de Linux acepta a mujeres y minorías porque todo lo que eres es una
+dirección de correo electrónico. El aspecto internacional también ayuda a
+nivelar el campo de juego porque no puede adivinar el género basado en
+el nombre de una persona. Un hombre puede llamarse Andrea y una mujer puede
+llamarse Pat. La mayoría de las mujeres que han trabajado en el kernel de
+Linux y han expresado una opinión han tenido experiencias positivas.
+
+La barrera del idioma puede causar problemas a algunas personas que no se
+sientes cómodas con el inglés. Un buen dominio del idioma puede ser
+necesario para transmitir ideas correctamente en las listas de correo, por
+lo que le recomendamos que revise sus correos electrónicos para asegurarse
+de que tengan sentido en inglés antes de enviarlos.
+
+Divida sus cambios
+---------------------
+
+La comunidad del kernel de Linux no acepta con gusto grandes fragmentos de
+código, sobretodo a la vez. Los cambios deben introducirse correctamente,
+discutidos y divididos en pequeñas porciones individuales. Esto es casi
+exactamente lo contrario de lo que las empresas están acostumbradas a hacer.
+Su propuesta también debe introducirse muy temprano en el proceso de
+desarrollo, de modo que pueda recibir comentarios sobre lo que está
+haciendo. También deje que la comunidad sienta que está trabajando con
+ellos, y no simplemente usándolos como un vertedero para su función. Sin
+embargo, no envíe 50 correos electrónicos a una vez a una lista de correo,
+su serie de parches debe casi siempre ser más pequeña que eso.
+
+Las razones para dividir las cosas son las siguientes:
+
+1) Los cambios pequeños aumentan la probabilidad de que sus parches sean
+   aplicados, ya que no requieren mucho tiempo o esfuerzo para verificar su
+   exactitud. Un parche de 5 líneas puede ser aplicado por un maintainer
+   con apenas una segunda mirada. Sin embargo, un parche de 500 líneas
+   puede tardar horas en ser revisado en términos de corrección (el tiempo
+   que toma es exponencialmente proporcional al tamaño del parche, o algo
+   así).
+
+   Los parches pequeños también facilitan la depuración cuando algo falla.
+   Es mucho más fácil retirar los parches uno por uno que diseccionar un
+   parche muy grande después de haber sido aplicado (y roto alguna cosa).
+
+2) Es importante no solo enviar pequeños parches, sino también reescribir
+   y simplificar (o simplemente reordenar) los parches antes de enviarlos.
+
+Esta es una analogía del desarrollador del kernel Al Viro (traducida):
+
+	*"Piense en un maestro que califica la tarea de un estudiante de
+	matemáticas. El maestro no quiere ver los intentos y errores del
+	estudiante antes de que se les ocurriera la solución. Quiere ver la
+	respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca
+	presentaría su trabajo intermedio antes de tener la solución final.*
+
+	* Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
+	revisores no quieren ver el proceso de pensamiento detrás de la solución
+	al problema que se está resolviendo. Quieren ver un solución simple y
+	elegante."*
+
+Puede resultar un reto mantener el equilibrio entre presentar una solución
+elegante y trabajar junto a la comunidad, discutiendo su trabajo inacabado.
+Por lo tanto, es bueno comenzar temprano en el proceso para obtener
+"feedback" y mejorar su trabajo, pero también mantenga sus cambios en
+pequeños trozos que pueden ser aceptados, incluso cuando toda su labor no
+está listo para inclusión en un momento dado.
+
+También tenga en cuenta que no es aceptable enviar parches para su
+inclusión que están sin terminar y serán "arreglados más tarde".
+
+Justifique sus cambios
+----------------------
+
+Además de dividir sus parches, es muy importante que deje a la comunidad de
+Linux sabe por qué deberían agregar este cambio. Nuevas características
+debe justificarse como necesarias y útiles.
+
+Documente sus cambios
+--------------------
+
+Cuando envíe sus parches, preste especial atención a lo que dice en el
+texto de su correo electrónico. Esta información se convertirá en el
+ChangeLog del parche, y se conservará para que todos la vean, todo el
+tiempo. Debe describir el parche por completo y contener:
+
+  - por que los cambios son necesarios
+  - el diseño general de su propuesta
+  - detalles de implementación
+  - resultados de sus experimentos
+
+Para obtener más detalles sobre cómo debería quedar todo esto, consulte la
+sección ChangeLog del documento:
+
+  "The Perfect Patch"
+      https://www.ozlabs.org/~akpm/stuff/tpp.txt
+
+Todas estas cuestiones son a veces son muy difíciles de conseguir. Puede
+llevar años perfeccionar estas prácticas (si es que lo hace). Es un proceso
+continuo de mejora que requiere mucha paciencia y determinación. Pero no se
+rinda, es posible. Muchos lo han hecho antes, y cada uno tuvo que comenzar
+exactamente donde está usted ahora.
+
+
+----------
+
+Gracias a Paolo Ciarrocchi que permitió que la sección "Development Process"
+se basara en el texto que había escrito (https://lwn.net/Articles/94386/),
+y a Randy Dunlap y Gerrit Huizenga por algunas de la lista de cosas que
+debes y no debes decir. También gracias a Pat Mochel, Hanna Linder, Randy
+Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook,
+Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk,
+Keri Harris, Frans Pop, David A. Wheeler, Junio ​​Hamano, Michael Kerrisk y
+Alex Shepard por su revisión, comentarios y contribuciones. Sin su ayuda,
+este documento no hubiera sido posible.
+
+Maintainer: Greg Kroah-Hartman <greg@kroah.com>
diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst
index bf6a24a2399d..1cc566058f2a 100644
--- a/Documentation/translations/sp_SP/index.rst
+++ b/Documentation/translations/sp_SP/index.rst
@@ -71,3 +71,10 @@ constante desarrollo. Las mejoras en la documentación siempre son
 bienvenidas; de modo que, si desea ayudar, únase a la lista de correo de
 linux-doc en vger.kernel.org.

+Traducciones al español
+=======================
+
+.. toctree::
+   :maxdepth: 1
+
+   howto
--
2.34.1

Re: [PATCH 0/2] Documentation: Start Spanish translation and include HOWTO

[Jonathan Corbet]

Carlos Bilbao <carlos.bilbao@amd.com> writes:

> Spanish is the second most spoken language in the world. This patch set
> starts the process of translating critical kernel documentation into the
> Spanish language.
>
> Carlos Bilbao (2):
>   Documentation: Start translations to Spanish
>   Documentation: Add HOWTO Spanish translation into rst based build system
>
>  Documentation/translations/index.rst          |   1 +
>  .../translations/sp_SP/disclaimer-sp.rst      |   6 +
>  Documentation/translations/sp_SP/howto.rst    | 619 ++++++++++++++++++
>  Documentation/translations/sp_SP/index.rst    |  80 +++
>  4 files changed, 706 insertions(+)
>  create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
>  create mode 100644 Documentation/translations/sp_SP/howto.rst
>  create mode 100644 Documentation/translations/sp_SP/index.rst

I'm happy to see a Spanish translation of the docs, certainly.  I do
worry, though, that the desire to create translations tends to exceed
the desire to keep them maintained and current over time. Is it your
plan to continue to maintain these going forward?  Is anybody else
planning to help you with this task?

Along those lines, a MAINTAINERS entry for the Spanish translation would
be a good thing to add.

Thanks,

jon

Re: [PATCH 2/2] Documentation: Add HOWTO Spanish translation into rst based build system

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 7284 bytes --]

Hi Carlos,

I love your patch! Perhaps something to improve:

[auto build test WARNING on lwn/docs-next]
[also build test WARNING on linus/master v6.0 next-20221014]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Carlos-Bilbao/Documentation-Start-Spanish-translation-and-include-HOWTO/20221014-025417
base:   git://git.lwn.net/linux.git docs-next
reproduce:
        # https://github.com/intel-lab-lkp/linux/commit/85ae76004fce3a5a202bd65a506b9b8cac1b5e32
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Carlos-Bilbao/Documentation-Start-Spanish-translation-and-include-HOWTO/20221014-025417
        git checkout 85ae76004fce3a5a202bd65a506b9b8cac1b5e32
        make menuconfig
        # enable CONFIG_COMPILE_TEST, CONFIG_WARN_MISSING_DOCUMENTS, CONFIG_WARN_ABI_ERRORS
        make htmldocs

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> Documentation/translations/sp_SP/howto.rst:186: WARNING: Title underline too short.
>> Documentation/translations/sp_SP/howto.rst:276: WARNING: Inline emphasis start-string without end-string.
>> Documentation/translations/sp_SP/howto.rst:277: WARNING: Block quote ends without a blank line; unexpected unindent.
>> Documentation/translations/sp_SP/howto.rst:560: WARNING: Bullet list ends without a blank line; unexpected unindent.

vim +186 Documentation/translations/sp_SP/howto.rst

   181	
   182		make latexdocs
   183		make epubdocs
   184	
   185	Convertirse en un/a desarrollador/a de kernel
 > 186	-------------------------------------------
   187	
   188	Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
   189	el proyecto Linux KernelNewbies:
   190	
   191		https://kernelnewbies.org
   192	
   193	Consiste en una útil lista de correo donde puede preguntar casi cualquier
   194	tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en
   195	los archivos primero, antes de preguntar algo que ya ha sido respondido en
   196	el pasado.) También tiene un canal IRC que puede usar para hacer preguntas
   197	en en tiempo real, y una gran cantidad de documentación útil que es útil
   198	para ir aprendiendo sobre el desarrollo del kernel de Linux.
   199	
   200	El sitio web tiene información básica sobre la organización del código,
   201	subsistemas, y proyectos actuales (tanto dentro como fuera del árbol).
   202	También describe alguna información logística básica, como cómo compilar
   203	un kernel y aplicar un parche.
   204	
   205	Si no sabe por dónde quiere empezar, pero quieres buscar alguna tarea que
   206	comenzar a hacer para unirse a la comunidad de desarrollo del kernel,
   207	acuda al proyecto Linux Kernel Janitor:
   208	
   209		https://kernelnewbies.org/KernelJanitors
   210	
   211	Es un gran lugar para comenzar. Describe una lista de problemas
   212	relativamente simples que deben limpiarse y corregirse dentro del codigo
   213	fuente del kernel de Linux árbol de fuentes. Trabajando con los
   214	desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos
   215	para incluir su parche en el árbol del kernel de Linux, y posiblemente
   216	descubrir en la dirección en que trabajar a continuación, si no tiene ya
   217	una idea.
   218	
   219	Antes de realizar cualquier modificación real al código del kernel de
   220	Linux, es imperativo entender cómo funciona el código en cuestión. Para
   221	este propósito, nada es mejor que leerlo directamente (lo más complicado
   222	está bien comentado), tal vez incluso con la ayuda de herramientas
   223	especializadas. Una de esas herramientas que se recomienda especialmente
   224	es el proyecto Linux Cross-Reference, que es capaz de presentar el código
   225	fuente en un formato de página web indexada y autorreferencial. Una
   226	excelente puesta al día del repositorio del código del kernel se puede
   227	encontrar en:
   228	
   229		https://elixir.bootlin.com/
   230	
   231	El proceso de desarrollo
   232	------------------------
   233	
   234	El proceso de desarrollo del kernel de Linux consiste actualmente de
   235	diferentes "branches" (ramas) con muchos distintos subsistemas específicos
   236	a cada una de ellas. Las diferentes ramas son:
   237	
   238	  - El código principal de Linus (mainline tree)
   239	  - Varios árboles estables con múltiples major numbers
   240	  - Subsistemas específicos
   241	  - linux-next, para integración y testing
   242	
   243	Mainline tree (Árbol principal)
   244	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   245	
   246	El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en
   247	https://kernel.org o en su repo.  El proceso de desarrollo es el siguiente:
   248	
   249	  - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos
   250	    semanas, durante este período de tiempo, los maintainers pueden enviar
   251	    grandes modificaciones a Linus, por lo general los parches que ya se
   252	    han incluido en el linux-next durante unas semanas. La forma preferida
   253	    de enviar grandes cambios es usando git (la herramienta de
   254	    administración de codigo fuente del kernel, más información al respecto
   255	    en https://git-scm.com/), pero los parches simples también son validos.
   256	  - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra
   257	    en hacer que el kernel nuevo lo más estable ("solido") posible. La
   258	    mayoría de los parches en este punto debe arreglar una regresión. Los
   259	    errores que siempre han existido no son regresiones, por lo tanto, solo
   260	    envíe este tipo de correcciones si son importantes. Tenga en cuenta que
   261	    se podría aceptar un controlador (o sistema de archivos) completamente
   262	    nuevo después de -rc1 porque no hay riesgo de causar regresiones con
   263	    tal cambio, siempre y cuando el cambio sea autónomo y no afecte áreas
   264	    fuera del código que se está agregando. git se puede usar para enviar
   265	    parches a Linus después de que se lance -rc1, pero los parches también
   266	    deben ser enviado a una lista de correo pública para su revisión.
   267	  - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git
   268	    actual esta en un estado razonablemente sano y adecuado para la prueba.
   269	    La meta es lanzar un nuevo kernel -rc cada semana.
   270	  - El proceso continúa hasta que el kernel se considera "listo", y esto
   271	    puede durar alrededor de 6 semanas.
   272	
   273	Vale la pena mencionar lo que Andrew Morton escribió en las listas de
   274	correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
   275	
 > 276		*"Nadie sabe cuándo se publicara un nuevo kernel, porque esto sucede
 > 277	    de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
   278	    una línea temporal preconcebida."*
   279	

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

[-- Attachment #2: config --]
[-- Type: text/plain, Size: 38516 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 6.0.0-rc1 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc-11 (Debian 11.3.0-5) 11.3.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=110300
CONFIG_CLANG_VERSION=0
CONFIG_AS_IS_GNU=y
CONFIG_AS_VERSION=23890
CONFIG_LD_IS_BFD=y
CONFIG_LD_VERSION=23890
CONFIG_LLD_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_CAN_LINK_STATIC=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y
CONFIG_PAHOLE_VERSION=123
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_COMPILE_TEST=y
# CONFIG_WERROR is not set
CONFIG_LOCALVERSION=""
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_HAVE_KERNEL_ZSTD=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
# CONFIG_KERNEL_ZSTD is not set
CONFIG_DEFAULT_INIT=""
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_WATCH_QUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# end of IRQ subsystem

CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_HAVE_POSIX_CPU_TIMERS_TASK_WORK=y
CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US=100
# end of Timers subsystem

CONFIG_HAVE_EBPF_JIT=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y

#
# BPF subsystem
#
# CONFIG_BPF_SYSCALL is not set
# end of BPF subsystem

CONFIG_PREEMPT_NONE_BUILD=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_DYNAMIC is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_PSI is not set
# end of CPU/Task time and stats accounting

CONFIG_CPU_ISOLATION=y

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
# end of RCU Subsystem

# CONFIG_IKCONFIG is not set
# CONFIG_IKHEADERS is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y

#
# Scheduler features
#
# end of Scheduler features

CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_CC_HAS_INT128=y
CONFIG_CC_IMPLICIT_FALLTHROUGH="-Wimplicit-fallthrough=5"
CONFIG_GCC12_NO_ARRAY_BOUNDS=y
CONFIG_ARCH_SUPPORTS_INT128=y
# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_TIME_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_BOOT_CONFIG is not set
# CONFIG_INITRAMFS_PRESERVE_MTIME is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_LD_ORPHAN_WARN=y
CONFIG_SYSCTL=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
# CONFIG_EXPERT is not set
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_FUTEX_PI=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_IO_URING=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_MEMBARRIER=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
CONFIG_RSEQ=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# end of Kernel Performance Events And Counters

# CONFIG_PROFILING is not set
# end of General setup

CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_NR_GPIO=1024
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

#
# Processor type and features
#
# CONFIG_SMP is not set
CONFIG_X86_FEATURE_NAMES=y
CONFIG_X86_MPPARSE=y
# CONFIG_GOLDFISH is not set
# CONFIG_X86_CPU_RESCTRL is not set
# CONFIG_X86_EXTENDED_PLATFORM is not set
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
# CONFIG_HYPERVISOR_GUEST is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_IA32_FEAT_CTL=y
CONFIG_X86_VMX_FEATURE_NAMES=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_HYGON=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_ZHAOXIN=y
CONFIG_HPET_TIMER=y
CONFIG_DMI=y
CONFIG_NR_CPUS_RANGE_BEGIN=1
CONFIG_NR_CPUS_RANGE_END=1
CONFIG_NR_CPUS_DEFAULT=1
CONFIG_NR_CPUS=1
CONFIG_UP_LATE_INIT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
# CONFIG_X86_MCE is not set

#
# Performance monitoring
#
# CONFIG_PERF_EVENTS_AMD_POWER is not set
# CONFIG_PERF_EVENTS_AMD_UNCORE is not set
# CONFIG_PERF_EVENTS_AMD_BRS is not set
# end of Performance monitoring

CONFIG_X86_16BIT=y
CONFIG_X86_ESPFIX64=y
CONFIG_X86_VSYSCALL_EMULATION=y
# CONFIG_X86_IOPL_IOPERM is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_X86_5LEVEL is not set
CONFIG_X86_DIRECT_GBPAGES=y
# CONFIG_AMD_MEM_ENCRYPT is not set
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_X86_UMIP=y
CONFIG_CC_HAS_IBT=y
# CONFIG_X86_KERNEL_IBT is not set
# CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS is not set
CONFIG_X86_INTEL_TSX_MODE_OFF=y
# CONFIG_X86_INTEL_TSX_MODE_ON is not set
# CONFIG_X86_INTEL_TSX_MODE_AUTO is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x1000000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x200000
CONFIG_LEGACY_VSYSCALL_XONLY=y
# CONFIG_LEGACY_VSYSCALL_NONE is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_MODIFY_LDT_SYSCALL=y
# CONFIG_STRICT_SIGALTSTACK_SIZE is not set
CONFIG_HAVE_LIVEPATCH=y
# end of Processor type and features

CONFIG_CC_HAS_SLS=y
CONFIG_CC_HAS_RETURN_THUNK=y
# CONFIG_SPECULATION_MITIGATIONS is not set
CONFIG_ARCH_HAS_ADD_PAGES=y
CONFIG_ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE=y

#
# Power management and ACPI options
#
# CONFIG_SUSPEND is not set
# CONFIG_PM is not set
CONFIG_ARCH_SUPPORTS_ACPI=y
# CONFIG_ACPI is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# end of CPU Frequency scaling

#
# CPU Idle
#
# CONFIG_CPU_IDLE is not set
# end of CPU Idle
# end of Power management and ACPI options

#
# Bus options (PCI etc.)
#
CONFIG_ISA_DMA_API=y
# end of Bus options (PCI etc.)

#
# Binary Emulations
#
# CONFIG_IA32_EMULATION is not set
# CONFIG_X86_X32_ABI is not set
# end of Binary Emulations

CONFIG_HAVE_KVM=y
# CONFIG_VIRTUALIZATION is not set
CONFIG_AS_AVX512=y
CONFIG_AS_SHA1_NI=y
CONFIG_AS_SHA256_NI=y
CONFIG_AS_TPAUSE=y

#
# General architecture-dependent options
#
CONFIG_GENERIC_ENTRY=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_STATIC_CALL_SELFTEST is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_ARCH_CORRECT_STACKTRACE_ON_KRETPROBE=y
CONFIG_HAVE_FUNCTION_ERROR_INJECTION=y
CONFIG_HAVE_NMI=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_NMI_SUPPORT=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
CONFIG_ARCH_HAS_SET_MEMORY=y
CONFIG_ARCH_HAS_SET_DIRECT_MAP=y
CONFIG_HAVE_ARCH_THREAD_STRUCT_WHITELIST=y
CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y
CONFIG_ARCH_WANTS_NO_INSTR=y
CONFIG_HAVE_ASM_MODVERSIONS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_RSEQ=y
CONFIG_HAVE_FUNCTION_ARG_ACCESS_API=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_HARDLOCKUP_DETECTOR_PERF=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_HAVE_ARCH_JUMP_LABEL_RELATIVE=y
CONFIG_MMU_GATHER_MERGE_VMAS=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_HAVE_ARCH_SECCOMP=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
# CONFIG_SECCOMP is not set
CONFIG_HAVE_ARCH_STACKLEAK=y
CONFIG_HAVE_STACKPROTECTOR=y
# CONFIG_STACKPROTECTOR is not set
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
CONFIG_LTO_NONE=y
CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y
CONFIG_HAVE_CONTEXT_TRACKING_USER=y
CONFIG_HAVE_CONTEXT_TRACKING_USER_OFFSTACK=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOVE_PUD=y
CONFIG_HAVE_MOVE_PMD=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
CONFIG_HAVE_ARCH_HUGE_VMAP=y
CONFIG_HAVE_ARCH_HUGE_VMALLOC=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_HAVE_ARCH_SOFT_DIRTY=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
CONFIG_HAVE_SOFTIRQ_ON_OWN_STACK=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
CONFIG_HAVE_EXIT_THREAD=y
CONFIG_ARCH_MMAP_RND_BITS=28
CONFIG_PAGE_SIZE_LESS_THAN_64KB=y
CONFIG_PAGE_SIZE_LESS_THAN_256KB=y
CONFIG_HAVE_OBJTOOL=y
CONFIG_HAVE_JUMP_LABEL_HACK=y
CONFIG_HAVE_NOINSTR_HACK=y
CONFIG_HAVE_NOINSTR_VALIDATION=y
CONFIG_HAVE_UACCESS_VALIDATION=y
CONFIG_HAVE_STACK_VALIDATION=y
CONFIG_HAVE_RELIABLE_STACKTRACE=y
# CONFIG_COMPAT_32BIT_TIME is not set
CONFIG_HAVE_ARCH_VMAP_STACK=y
# CONFIG_VMAP_STACK is not set
CONFIG_HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET=y
CONFIG_RANDOMIZE_KSTACK_OFFSET=y
# CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT is not set
CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
CONFIG_HAVE_ARCH_PREL32_RELOCATIONS=y
CONFIG_ARCH_HAS_MEM_ENCRYPT=y
CONFIG_HAVE_STATIC_CALL=y
CONFIG_HAVE_STATIC_CALL_INLINE=y
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y
CONFIG_ARCH_WANT_LD_ORPHAN_WARN=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_PAGE_TABLE_CHECK=y
CONFIG_ARCH_HAS_ELFCORE_COMPAT=y
CONFIG_ARCH_HAS_PARANOID_L1D_FLUSH=y
CONFIG_DYNAMIC_SIGFRAME=y

#
# GCOV-based kernel profiling
#
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
# end of GCOV-based kernel profiling

CONFIG_HAVE_GCC_PLUGINS=y
# CONFIG_GCC_PLUGINS is not set
# end of General architecture-dependent options

CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
# CONFIG_BLOCK_LEGACY_AUTOLOAD is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_DEV_ZONED is not set
# CONFIG_BLK_WBT is not set
# CONFIG_BLK_SED_OPAL is not set
# CONFIG_BLK_INLINE_ENCRYPTION is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_EFI_PARTITION=y
# end of Partition Types

#
# IO Schedulers
#
# CONFIG_MQ_IOSCHED_DEADLINE is not set
# CONFIG_MQ_IOSCHED_KYBER is not set
# CONFIG_IOSCHED_BFQ is not set
# end of IO Schedulers

CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE=y
CONFIG_ARCH_HAS_SYNC_CORE_BEFORE_USERMODE=y
CONFIG_ARCH_HAS_SYSCALL_WRAPPER=y

#
# Executable file formats
#
# CONFIG_BINFMT_ELF is not set
# CONFIG_BINFMT_SCRIPT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y
# end of Executable file formats

#
# Memory Management options
#
# CONFIG_SWAP is not set

#
# SLAB allocator options
#
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLAB_MERGE_DEFAULT is not set
# CONFIG_SLAB_FREELIST_RANDOM is not set
# CONFIG_SLAB_FREELIST_HARDENED is not set
# CONFIG_SLUB_STATS is not set
# end of SLAB allocator options

# CONFIG_SHUFFLE_PAGE_ALLOCATOR is not set
# CONFIG_COMPAT_BRK is not set
CONFIG_SPARSEMEM=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
# CONFIG_SPARSEMEM_VMEMMAP is not set
CONFIG_HAVE_FAST_GUP=y
CONFIG_EXCLUSIVE_SYSTEM_RAM=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
# CONFIG_COMPACTION is not set
# CONFIG_PAGE_REPORTING is not set
CONFIG_PHYS_ADDR_T_64BIT=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_WANTS_THP_SWAP=y
# CONFIG_TRANSPARENT_HUGEPAGE is not set
CONFIG_NEED_PER_CPU_KM=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
# CONFIG_CMA is not set
CONFIG_GENERIC_EARLY_IOREMAP=y
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CURRENT_STACK_POINTER=y
CONFIG_ARCH_HAS_PTE_DEVMAP=y
CONFIG_ZONE_DMA=y
CONFIG_ZONE_DMA32=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_PERCPU_STATS is not set

#
# GUP_TEST needs to have DEBUG_FS enabled
#
CONFIG_ARCH_HAS_PTE_SPECIAL=y
CONFIG_SECRETMEM=y
# CONFIG_ANON_VMA_NAME is not set
# CONFIG_USERFAULTFD is not set

#
# Data Access Monitoring
#
# CONFIG_DAMON is not set
# end of Data Access Monitoring
# end of Memory Management options

# CONFIG_NET is not set

#
# Device Drivers
#
CONFIG_HAVE_EISA=y
# CONFIG_EISA is not set
CONFIG_HAVE_PCI=y
# CONFIG_PCI is not set
# CONFIG_PCCARD is not set

#
# Generic Driver Options
#
# CONFIG_UEVENT_HELPER is not set
# CONFIG_DEVTMPFS is not set
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set

#
# Firmware loader
#
CONFIG_FW_LOADER=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER is not set
# CONFIG_FW_LOADER_COMPRESS is not set
# CONFIG_FW_UPLOAD is not set
# end of Firmware loader

CONFIG_ALLOW_DEV_COREDUMP=y
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_GENERIC_CPU_VULNERABILITIES=y
# end of Generic Driver Options

#
# Bus devices
#
# CONFIG_ARM_INTEGRATOR_LM is not set
# CONFIG_BT1_APB is not set
# CONFIG_BT1_AXI is not set
# CONFIG_HISILICON_LPC is not set
# CONFIG_INTEL_IXP4XX_EB is not set
# CONFIG_QCOM_EBI2 is not set
# CONFIG_MHI_BUS is not set
# CONFIG_MHI_BUS_EP is not set
# end of Bus devices

#
# Firmware Drivers
#

#
# ARM System Control and Management Interface Protocol
#
# CONFIG_ARM_SCMI_PROTOCOL is not set
# end of ARM System Control and Management Interface Protocol

# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DMIID is not set
# CONFIG_DMI_SYSFS is not set
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
# CONFIG_FW_CFG_SYSFS is not set
# CONFIG_SYSFB_SIMPLEFB is not set
# CONFIG_BCM47XX_NVRAM is not set
# CONFIG_GOOGLE_FIRMWARE is not set

#
# Tegra firmware driver
#
# end of Tegra firmware driver
# end of Firmware Drivers

# CONFIG_GNSS is not set
# CONFIG_MTD is not set
# CONFIG_OF is not set
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
# CONFIG_PARPORT is not set
# CONFIG_BLK_DEV is not set

#
# NVME Support
#
# CONFIG_NVME_FC is not set
# end of NVME Support

#
# Misc devices
#
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_QCOM_COINCELL is not set
# CONFIG_SRAM is not set
# CONFIG_XILINX_SDFEC is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_93CX6 is not set
# end of EEPROM support

#
# Texas Instruments shared transport line discipline
#
# end of Texas Instruments shared transport line discipline

#
# Altera FPGA firmware download module (requires I2C)
#
# CONFIG_ECHO is not set
# CONFIG_PVPANIC is not set
# end of Misc devices

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# end of SCSI device support

# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# end of IEEE 1394 (FireWire) support

# CONFIG_MACINTOSH_DRIVERS is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
# CONFIG_RMI4_CORE is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
# CONFIG_GAMEPORT is not set
# end of Hardware I/O ports
# end of Input device support

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_LDISC_AUTOLOAD is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
# CONFIG_SERIAL_ATMEL is not set
# CONFIG_SERIAL_MESON is not set
# CONFIG_SERIAL_CLPS711X is not set
# CONFIG_SERIAL_SAMSUNG is not set
# CONFIG_SERIAL_TEGRA is not set
# CONFIG_SERIAL_IMX is not set
# CONFIG_SERIAL_UARTLITE is not set
# CONFIG_SERIAL_SH_SCI is not set
# CONFIG_SERIAL_MSM is not set
# CONFIG_SERIAL_VT8500 is not set
# CONFIG_SERIAL_OMAP is not set
# CONFIG_SERIAL_LANTIQ is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_BCM63XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_MXS_AUART is not set
# CONFIG_SERIAL_MPS2_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_FSL_LINFLEXUART is not set
# CONFIG_SERIAL_ST_ASC is not set
# CONFIG_SERIAL_STM32 is not set
# CONFIG_SERIAL_OWL is not set
# CONFIG_SERIAL_RDA is not set
# CONFIG_SERIAL_LITEUART is not set
# CONFIG_SERIAL_SUNPLUS is not set
# end of Serial drivers

# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NULL_TTY is not set
# CONFIG_SERIAL_DEV_BUS is not set
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_ASPEED_KCS_IPMI_BMC is not set
# CONFIG_NPCM7XX_KCS_IPMI_BMC is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_MWAVE is not set
# CONFIG_DEVMEM is not set
# CONFIG_NVRAM is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
# CONFIG_RANDOM_TRUST_CPU is not set
# CONFIG_RANDOM_TRUST_BOOTLOADER is not set
# end of Character devices

#
# I2C support
#
# CONFIG_I2C is not set
# end of I2C support

# CONFIG_I3C is not set
# CONFIG_SPI is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set
# CONFIG_PPS is not set

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK_OPTIONAL=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# end of PTP clock support

# CONFIG_PINCTRL is not set
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
# CONFIG_POWER_RESET is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SUN4I_GPADC is not set
# CONFIG_MFD_AT91_USART is not set
# CONFIG_MFD_MADERA is not set
# CONFIG_MFD_EXYNOS_LPASS is not set
# CONFIG_MFD_MXS_LRADC is not set
# CONFIG_MFD_MX25_TSADC is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_MT6397 is not set
# CONFIG_MFD_PM8XXX is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_SUN6I_PRCM is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_TQMX86 is not set
# CONFIG_MFD_STM32_LPTIMER is not set
# CONFIG_MFD_STM32_TIMERS is not set
# end of Multifunction device drivers

# CONFIG_REGULATOR is not set
# CONFIG_RC_CORE is not set

#
# CEC support
#
# CONFIG_MEDIA_CEC_SUPPORT is not set
# end of CEC support

# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_IMX_IPUV3_CORE is not set
# CONFIG_DRM is not set

#
# ARM devices
#
# end of ARM devices

#
# Frame buffer Devices
#
# CONFIG_FB is not set
# CONFIG_MMP_DISP is not set
# end of Frame buffer Devices

#
# Backlight & LCD device support
#
# CONFIG_LCD_CLASS_DEVICE is not set
# CONFIG_BACKLIGHT_CLASS_DEVICE is not set
# end of Backlight & LCD device support

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
# end of Console display driver support
# end of Graphics support

# CONFIG_SOUND is not set

#
# HID support
#
# CONFIG_HID is not set
# end of HID support

CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_SUPPORT is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
CONFIG_EDAC_ATOMIC_SCRUB=y
CONFIG_EDAC_SUPPORT=y
CONFIG_RTC_LIB=y
CONFIG_RTC_MC146818_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set

#
# DMABUF options
#
# CONFIG_SYNC_FILE is not set
# CONFIG_DMABUF_HEAPS is not set
# end of DMABUF options

# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VFIO is not set
# CONFIG_VIRT_DRIVERS is not set
# CONFIG_VIRTIO_MENU is not set
# CONFIG_VHOST_MENU is not set

#
# Microsoft Hyper-V guest support
#
# end of Microsoft Hyper-V guest support

# CONFIG_GREYBUS is not set
# CONFIG_COMEDI is not set
# CONFIG_STAGING is not set
# CONFIG_CHROME_PLATFORMS is not set
# CONFIG_MELLANOX_PLATFORM is not set
# CONFIG_OLPC_XO175 is not set
# CONFIG_SURFACE_PLATFORMS is not set
# CONFIG_X86_PLATFORM_DEVICES is not set
# CONFIG_COMMON_CLK is not set
# CONFIG_HWSPINLOCK is not set

#
# Clock Source drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
# CONFIG_BCM2835_TIMER is not set
# CONFIG_BCM_KONA_TIMER is not set
# CONFIG_DAVINCI_TIMER is not set
# CONFIG_DIGICOLOR_TIMER is not set
# CONFIG_OMAP_DM_TIMER is not set
# CONFIG_DW_APB_TIMER is not set
# CONFIG_FTTMR010_TIMER is not set
# CONFIG_IXP4XX_TIMER is not set
# CONFIG_MESON6_TIMER is not set
# CONFIG_OWL_TIMER is not set
# CONFIG_RDA_TIMER is not set
# CONFIG_SUN4I_TIMER is not set
# CONFIG_TEGRA_TIMER is not set
# CONFIG_VT8500_TIMER is not set
# CONFIG_NPCM7XX_TIMER is not set
# CONFIG_ASM9260_TIMER is not set
# CONFIG_CLKSRC_DBX500_PRCMU is not set
# CONFIG_CLPS711X_TIMER is not set
# CONFIG_MXS_TIMER is not set
# CONFIG_NSPIRE_TIMER is not set
# CONFIG_INTEGRATOR_AP_TIMER is not set
# CONFIG_CLKSRC_PISTACHIO is not set
# CONFIG_CLKSRC_STM32_LP is not set
# CONFIG_ARMV7M_SYSTICK is not set
# CONFIG_ATMEL_PIT is not set
# CONFIG_ATMEL_ST is not set
# CONFIG_CLKSRC_SAMSUNG_PWM is not set
# CONFIG_FSL_FTM_TIMER is not set
# CONFIG_OXNAS_RPS_TIMER is not set
# CONFIG_MTK_TIMER is not set
# CONFIG_SH_TIMER_CMT is not set
# CONFIG_SH_TIMER_MTU2 is not set
# CONFIG_RENESAS_OSTM is not set
# CONFIG_SH_TIMER_TMU is not set
# CONFIG_EM_TIMER_STI is not set
# CONFIG_CLKSRC_PXA is not set
# CONFIG_TIMER_IMX_SYS_CTR is not set
# CONFIG_CLKSRC_ST_LPC is not set
# CONFIG_GXP_TIMER is not set
# CONFIG_MSC313E_TIMER is not set
# CONFIG_MICROCHIP_PIT64B is not set
# end of Clock Source drivers

# CONFIG_MAILBOX is not set
# CONFIG_IOMMU_SUPPORT is not set

#
# Remoteproc drivers
#
# CONFIG_REMOTEPROC is not set
# end of Remoteproc drivers

#
# Rpmsg drivers
#
# CONFIG_RPMSG_VIRTIO is not set
# end of Rpmsg drivers

#
# SOC (System On Chip) specific Drivers
#

#
# Amlogic SoC drivers
#
# CONFIG_MESON_CANVAS is not set
# CONFIG_MESON_CLK_MEASURE is not set
# CONFIG_MESON_GX_SOCINFO is not set
# CONFIG_MESON_MX_SOCINFO is not set
# end of Amlogic SoC drivers

#
# Apple SoC drivers
#
# CONFIG_APPLE_SART is not set
# end of Apple SoC drivers

#
# ASPEED SoC drivers
#
# CONFIG_ASPEED_LPC_CTRL is not set
# CONFIG_ASPEED_LPC_SNOOP is not set
# CONFIG_ASPEED_UART_ROUTING is not set
# CONFIG_ASPEED_P2A_CTRL is not set
# CONFIG_ASPEED_SOCINFO is not set
# end of ASPEED SoC drivers

# CONFIG_AT91_SOC_ID is not set
# CONFIG_AT91_SOC_SFR is not set

#
# Broadcom SoC drivers
#
# CONFIG_SOC_BCM63XX is not set
# CONFIG_SOC_BRCMSTB is not set
# end of Broadcom SoC drivers

#
# NXP/Freescale QorIQ SoC drivers
#
# end of NXP/Freescale QorIQ SoC drivers

#
# fujitsu SoC drivers
#
# end of fujitsu SoC drivers

#
# i.MX SoC drivers
#
# CONFIG_SOC_IMX8M is not set
# end of i.MX SoC drivers

#
# IXP4xx SoC drivers
#
# CONFIG_IXP4XX_QMGR is not set
# CONFIG_IXP4XX_NPE is not set
# end of IXP4xx SoC drivers

#
# Enable LiteX SoC Builder specific drivers
#
# CONFIG_LITEX_SOC_CONTROLLER is not set
# end of Enable LiteX SoC Builder specific drivers

#
# MediaTek SoC drivers
#
# CONFIG_MTK_CMDQ is not set
# CONFIG_MTK_DEVAPC is not set
# CONFIG_MTK_INFRACFG is not set
# CONFIG_MTK_SCPSYS is not set
# CONFIG_MTK_MMSYS is not set
# end of MediaTek SoC drivers

#
# Qualcomm SoC drivers
#
# CONFIG_QCOM_GENI_SE is not set
# CONFIG_QCOM_GSBI is not set
# CONFIG_QCOM_LLCC is not set
# CONFIG_QCOM_RPMH is not set
# CONFIG_QCOM_SPM is not set
# CONFIG_QCOM_ICC_BWMON is not set
# end of Qualcomm SoC drivers

# CONFIG_SOC_RENESAS is not set
# CONFIG_ROCKCHIP_GRF is not set
# CONFIG_SOC_SAMSUNG is not set
# CONFIG_SOC_TI is not set
# CONFIG_UX500_SOC_ID is not set

#
# Xilinx SoC drivers
#
# end of Xilinx SoC drivers
# end of SOC (System On Chip) specific Drivers

# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set

#
# IRQ chip support
#
# CONFIG_AL_FIC is not set
# CONFIG_RENESAS_INTC_IRQPIN is not set
# CONFIG_RENESAS_IRQC is not set
# CONFIG_RENESAS_RZA1_IRQC is not set
# CONFIG_RENESAS_RZG2L_IRQC is not set
# CONFIG_SL28CPLD_INTC is not set
# CONFIG_TS4800_IRQ is not set
# CONFIG_INGENIC_TCU_IRQ is not set
# CONFIG_IRQ_UNIPHIER_AIDET is not set
# CONFIG_MESON_IRQ_GPIO is not set
# CONFIG_IMX_IRQSTEER is not set
# CONFIG_IMX_INTMUX is not set
# CONFIG_EXYNOS_IRQ_COMBINER is not set
# CONFIG_MST_IRQ is not set
# CONFIG_MCHP_EIC is not set
# CONFIG_SUNPLUS_SP7021_INTC is not set
# end of IRQ chip support

# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set

#
# PHY Subsystem
#
# CONFIG_GENERIC_PHY is not set
# CONFIG_PHY_PISTACHIO_USB is not set
# CONFIG_PHY_CAN_TRANSCEIVER is not set

#
# PHY drivers for Broadcom platforms
#
# CONFIG_PHY_BCM63XX_USBH is not set
# CONFIG_BCM_KONA_USB2_PHY is not set
# end of PHY drivers for Broadcom platforms

# CONFIG_PHY_HI6220_USB is not set
# CONFIG_PHY_HI3660_USB is not set
# CONFIG_PHY_HI3670_USB is not set
# CONFIG_PHY_HI3670_PCIE is not set
# CONFIG_PHY_HISTB_COMBPHY is not set
# CONFIG_PHY_HISI_INNO_USB2 is not set
# CONFIG_PHY_PXA_28NM_HSIC is not set
# CONFIG_PHY_PXA_28NM_USB2 is not set
# CONFIG_PHY_PXA_USB is not set
# CONFIG_PHY_MMP3_USB is not set
# CONFIG_PHY_MMP3_HSIC is not set
# CONFIG_PHY_MT7621_PCI is not set
# CONFIG_PHY_RALINK_USB is not set
# CONFIG_PHY_RCAR_GEN3_USB3 is not set
# CONFIG_PHY_ROCKCHIP_DPHY_RX0 is not set
# CONFIG_PHY_ROCKCHIP_PCIE is not set
# CONFIG_PHY_EXYNOS_MIPI_VIDEO is not set
# CONFIG_PHY_SAMSUNG_USB2 is not set
# CONFIG_PHY_ST_SPEAR1310_MIPHY is not set
# CONFIG_PHY_ST_SPEAR1340_MIPHY is not set
# CONFIG_PHY_TEGRA194_P2U is not set
# CONFIG_PHY_DA8XX_USB is not set
# CONFIG_OMAP_CONTROL_PHY is not set
# CONFIG_TI_PIPE3 is not set
# CONFIG_PHY_INTEL_KEEMBAY_EMMC is not set
# CONFIG_PHY_INTEL_KEEMBAY_USB is not set
# CONFIG_PHY_INTEL_LGM_EMMC is not set
# CONFIG_PHY_XILINX_ZYNQMP is not set
# end of PHY Subsystem

# CONFIG_POWERCAP is not set
# CONFIG_MCB is not set

#
# Performance monitor support
#
# CONFIG_ARM_CCN is not set
# CONFIG_ARM_CMN is not set
# CONFIG_FSL_IMX8_DDR_PMU is not set
# CONFIG_XGENE_PMU is not set
# CONFIG_ARM_DMC620_PMU is not set
# CONFIG_MARVELL_CN10K_TAD_PMU is not set
# CONFIG_MARVELL_CN10K_DDR_PMU is not set
# end of Performance monitor support

# CONFIG_RAS is not set

#
# Android
#
# CONFIG_ANDROID_BINDER_IPC is not set
# end of Android

# CONFIG_DAX is not set
# CONFIG_NVMEM is not set

#
# HW tracing support
#
# CONFIG_STM is not set
# CONFIG_INTEL_TH is not set
# end of HW tracing support

# CONFIG_FPGA is not set
# CONFIG_TEE is not set
# CONFIG_SIOX is not set
# CONFIG_SLIMBUS is not set
# CONFIG_INTERCONNECT is not set
# CONFIG_COUNTER is not set
# CONFIG_PECI is not set
# CONFIG_HTE is not set
# end of Device Drivers

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_VALIDATE_FS_PARSER is not set
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_EXPORTFS=y
# CONFIG_EXPORTFS_BLOCK_OPS is not set
CONFIG_FILE_LOCKING=y
# CONFIG_FS_ENCRYPTION is not set
# CONFIG_FS_VERITY is not set
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY_USER is not set
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_FUSE_FS is not set
# CONFIG_OVERLAY_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set
# end of Caches

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
# end of CD-ROM/DVD Filesystems

#
# DOS/FAT/EXFAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EXFAT_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS3_FS is not set
# end of DOS/FAT/EXFAT/NT Filesystems

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
# CONFIG_PROC_CHILDREN is not set
CONFIG_PROC_PID_ARCH_STATUS=y
CONFIG_KERNFS=y
CONFIG_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLBFS is not set
CONFIG_ARCH_WANT_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y
CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
# CONFIG_CONFIGFS_FS is not set
# end of Pseudo filesystems

# CONFIG_MISC_FILESYSTEMS is not set
# CONFIG_NLS is not set
# CONFIG_UNICODE is not set
CONFIG_IO_WQ=y
# end of File systems

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y
# CONFIG_HARDENED_USERCOPY is not set
# CONFIG_FORTIFY_SOURCE is not set
# CONFIG_STATIC_USERMODEHELPER is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,bpf"

#
# Kernel hardening options
#

#
# Memory initialization
#
CONFIG_INIT_STACK_NONE=y
# CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not set
# CONFIG_INIT_ON_FREE_DEFAULT_ON is not set
CONFIG_CC_HAS_ZERO_CALL_USED_REGS=y
# CONFIG_ZERO_CALL_USED_REGS is not set
# end of Memory initialization

CONFIG_RANDSTRUCT_NONE=y
# end of Kernel hardening options
# end of Security options

# CONFIG_CRYPTO is not set

#
# Library routines
#
# CONFIG_PACKING is not set
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
# CONFIG_CORDIC is not set
# CONFIG_PRIME_NUMBERS is not set
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
CONFIG_ARCH_USE_SYM_ANNOTATIONS=y

#
# Crypto library routines
#
CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
# CONFIG_CRYPTO_LIB_CURVE25519 is not set
CONFIG_CRYPTO_LIB_POLY1305_RSIZE=11
# CONFIG_CRYPTO_LIB_POLY1305 is not set
# end of Crypto library routines

# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC64_ROCKSOFT is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC64 is not set
# CONFIG_CRC4 is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
# CONFIG_RANDOM32_SELFTEST is not set
# CONFIG_XZ_DEC is not set
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_SWIOTLB=y
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_IRQ_POLL is not set
CONFIG_HAVE_GENERIC_VDSO=y
CONFIG_GENERIC_GETTIMEOFDAY=y
CONFIG_GENERIC_VDSO_TIME_NS=y
CONFIG_ARCH_HAS_PMEM_API=y
CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y
CONFIG_ARCH_HAS_COPY_MC=y
CONFIG_ARCH_STACKWALK=y
CONFIG_STACKDEPOT=y
CONFIG_SBITMAP=y
# CONFIG_PARMAN is not set
# CONFIG_OBJAGG is not set
# end of Library routines

#
# Kernel hacking
#

#
# printk and dmesg options
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_PRINTK_CALLER is not set
# CONFIG_STACKTRACE_BUILD_ID is not set
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
CONFIG_CONSOLE_LOGLEVEL_QUIET=4
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DYNAMIC_DEBUG_CORE is not set
# CONFIG_SYMBOLIC_ERRNAME is not set
CONFIG_DEBUG_BUGVERBOSE=y
# end of printk and dmesg options

# CONFIG_DEBUG_KERNEL is not set

#
# Compile-time checks and compiler options
#
CONFIG_FRAME_WARN=2048
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_HEADERS_INSTALL is not set
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
CONFIG_OBJTOOL=y
# end of Compile-time checks and compiler options

#
# Generic Kernel Debugging Instruments
#
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_FS is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
# CONFIG_UBSAN is not set
CONFIG_HAVE_ARCH_KCSAN=y
CONFIG_HAVE_KCSAN_COMPILER=y
# end of Generic Kernel Debugging Instruments

#
# Networking Debugging
#
# end of Networking Debugging

#
# Memory Debugging
#
# CONFIG_PAGE_EXTENSION is not set
CONFIG_SLUB_DEBUG=y
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_PAGE_TABLE_CHECK is not set
# CONFIG_PAGE_POISONING is not set
# CONFIG_DEBUG_RODATA_TEST is not set
CONFIG_ARCH_HAS_DEBUG_WX=y
# CONFIG_DEBUG_WX is not set
CONFIG_GENERIC_PTDUMP=y
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE=y
# CONFIG_DEBUG_VM_PGTABLE is not set
CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP=y
CONFIG_HAVE_ARCH_KASAN=y
CONFIG_HAVE_ARCH_KASAN_VMALLOC=y
CONFIG_CC_HAS_KASAN_GENERIC=y
CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS=y
# CONFIG_KASAN is not set
CONFIG_HAVE_ARCH_KFENCE=y
# CONFIG_KFENCE is not set
# end of Memory Debugging

#
# Debug Oops, Lockups and Hangs
#
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_PANIC_TIMEOUT=0
CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y
# end of Debug Oops, Lockups and Hangs

#
# Scheduler Debugging
#
# end of Scheduler Debugging

# CONFIG_DEBUG_TIMEKEEPING is not set

#
# Lock Debugging (spinlocks, mutexes, etc...)
#
CONFIG_LOCK_DEBUGGING_SUPPORT=y
# CONFIG_WW_MUTEX_SELFTEST is not set
# end of Lock Debugging (spinlocks, mutexes, etc...)

# CONFIG_DEBUG_IRQFLAGS is not set
CONFIG_STACKTRACE=y
# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set

#
# Debug kernel data structures
#
# CONFIG_BUG_ON_DATA_CORRUPTION is not set
# end of Debug kernel data structures

#
# RCU Debugging
#
# end of RCU Debugging

CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_RETHOOK=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_FENTRY=y
CONFIG_HAVE_OBJTOOL_MCOUNT=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_HAVE_BUILDTIME_MCOUNT_SORT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_SAMPLE_FTRACE_DIRECT=y
CONFIG_HAVE_SAMPLE_FTRACE_DIRECT_MULTI=y
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y

#
# x86 Debugging
#
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_UNWINDER_ORC=y
# CONFIG_UNWINDER_FRAME_POINTER is not set
# end of x86 Debugging

#
# Kernel Testing and Coverage
#
# CONFIG_KUNIT is not set
CONFIG_ARCH_HAS_KCOV=y
CONFIG_CC_HAS_SANCOV_TRACE_PC=y
# CONFIG_KCOV is not set
# CONFIG_RUNTIME_TESTING_MENU is not set
CONFIG_ARCH_USE_MEMTEST=y
# CONFIG_MEMTEST is not set
# end of Kernel Testing and Coverage

CONFIG_WARN_MISSING_DOCUMENTS=y
CONFIG_WARN_ABI_ERRORS=y
# end of Kernel hacking

Re: [PATCH 2/2] Documentation: Add HOWTO Spanish translation into rst based build system

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 36153 bytes --]

¡Hola Carlos! Gracias for start writing Spanish translations. However,
the patch can be improved, see below.

On Thu, Oct 13, 2022 at 01:48:16PM -0500, Carlos Bilbao wrote:
> This commit adds Spanish translation of HOWTO document into rst based
> documentation build system.
> 

Better say "Translate HOWTO document into Spanish".

> Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
> ---
>  Documentation/translations/sp_SP/howto.rst | 619 +++++++++++++++++++++
>  Documentation/translations/sp_SP/index.rst |   7 +
>  2 files changed, 626 insertions(+)
>  create mode 100644 Documentation/translations/sp_SP/howto.rst
> 
> diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
> new file mode 100644
> index 000000000000..4cf8fa6b9f7c
> --- /dev/null
> +++ b/Documentation/translations/sp_SP/howto.rst
> @@ -0,0 +1,619 @@
> +.. include:: ./disclaimer-sp.rst
> +
> +:Original: :ref:`Documentation/process/howto.rst <process_howto>`
> +:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
> +
> +.. _sp_process_howto:
> +
> +Cómo participar en el desarrollo del kernel de Linux
> +====================================================
> +
> +Este documento es el principal punto de partida. Contiene instrucciones
> +sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
> +trabajar con el y en su desarrollo. El documento no tratará ningún aspecto
> +técnico relacionado con la programación del kernel, pero le ayudará
> +guiándole por el camino correcto.
> +
> +Si algo en este documento quedara obsoleto, envíe parches al maintainer de
> +este archivo, que se encuentra en la parte superior del documento.
> +
> +Introducción
> +------------
> +¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
> +kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
> +Linux para este dispositivo." El objetivo de este documento en enseñarle
> +todo cuanto necesita para conseguir esto, describiendo el proceso por el
> +que debe pasar, y con indicaciones de como trabajar con la comunidad.
> +También trata de explicar las razones por las cuales la comunidad trabaja
> +de la forma en que lo hace.
> +
> +El kernel esta principalmente escrito en C, con algunas partes que son
> +dependientes de la arquitectura en ensamblador. Un buen conocimiento de C
> +es necesario para desarrollar en el kernel. Lenguaje ensamblador (en
> +cualquier arquitectura) no es necesario excepto que planee realizar
> +desarrollo de bajo nivel para dicha arquitectura. Aunque no es un perfecto
> +sustituto para una educación sólida en C y/o años de experiencia, los
> +siguientes libros sirven, como mínimo, como referencia:
> +
> +- "The C Programming Language" de Kernighan e Ritchie [Prentice Hall]
> +- "Practical C Programming" de Steve Oualline [O'Reilly]
> +- "C:  A Reference Manual" de Harbison and Steele [Prentice Hall]
> +
> +El kernel está escrito usando GNU C y la cadena de herramientas GNU. Si
> +bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que
> +no aparecen en dicho estándar. El kernel usa un C independiente de entorno,
> +sin depender de la biblioteca C estándar, por lo que algunas partes del
> +estándar C no son compatibles. Divisiones de long long arbitrarios o
> +de coma flotante no son permitidas. En ocasiones, puede ser difícil de
> +entender las suposiciones que el kernel hace respecto a la cadena de
> +herramientas y las extensiones que usa, y desafortunadamente no hay
> +referencia definitiva para estos. Consulte las páginas de información de
> +gcc (`info gcc`) para obtener información al respecto.
> +
> +Recuerde que está tratando de aprender a trabajar con una comunidad de
> +desarrollo existente. Es un grupo diverso de personas, con altos estándares
> +de codificación, estilo y procedimiento. Estas normas han sido creadas a lo
> +largo del tiempo en función de lo que se ha encontrado que funciona mejor
> +para un equipo tan grande y geográficamente disperso. Trate de aprender
> +tanto como le sea posible acerca de estos estándares antes de tiempo, ya
> +que están bien documentados; no espere que la gente se adapte a usted o a
> +su forma de ser de hacer las cosas.
> +
> +Cuestiones legales
> +------------------
> +El código fuente del kernel de Linux se publica bajo licencia GPL. Por
> +favor, revise el archivo COPYING, presente en la carpeta principal del
> +fuente, para detalles de la licencia. Si tiene alguna otra pregunta
> +sobre licencias, contacte a un abogado, no pregunte en listas de discusión
> +del kernel de Linux. Las personas en estas listas no son abogadas, y no
> +debe confiar en sus opiniones en materia legal.
> +
> +Para preguntas y respuestas más frecuentes sobre la licencia GPL, consulte:
> +
> +	https://www.gnu.org/licenses/gpl-faq.html
> +
> +Documentacion
> +--------------
> +El código fuente del kernel de Linux tiene una gran variedad de documentos
> +que son increíblemente valiosos para aprender a interactuar con la
> +comunidad del kernel. Cuando se agregan nuevas funciones al kernel, se
> +recomienda que se incluyan nuevos archivos de documentación que expliquen
> +cómo usar la función. Cuando un cambio en el kernel hace que la interfaz
> +que el kernel expone espacio de usuario cambie, se recomienda que envíe la
> +información o un parche en las páginas del manual que expliquen el cambio
> +a mtk.manpages@gmail.com, y CC la lista linux-api@vger.kernel.org.
> +
> +Esta es la lista de archivos que están en el código fuente del kernel y son
> +de obligada lectura:
> +
> +  :ref:`Documentation/admin-guide/README.rst <readme>`
> +    Este archivo ofrece una breve descripción del kernel de Linux y
> +    describe lo que es necesario hacer para configurar y compilar el
> +    kernel. Quienes sean nuevos en el kernel deben comenzar aquí.
> +
> +  :ref:`Documentation/process/changes.rst <changes>`
> +    Este archivo proporciona una lista de los niveles mínimos de varios
> +    paquetes que son necesarios para construir y ejecutar el kernel
> +    exitosamente.
> +
> +  :ref:`Documentation/process/coding-style.rst <codingstyle>`
> +    Esto describe el estilo de código del kernel de Linux y algunas de los
> +    razones detrás de esto. Se espera que todo el código nuevo siga las
> +    directrices de este documento. La mayoría de los maintainers solo
> +    aceptarán parches si se siguen estas reglas, y muchas personas solo
> +    revisan el código si tiene el estilo adecuado.
> +
> +  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
> +    Este archivo describe en gran detalle cómo crear con éxito y enviar un
> +    parche, que incluye (pero no se limita a):
> +
> +       - Contenidos del correo electrónico (email)
> +       - Formato del email
> +       - A quien se debe enviar
> +
> +    Seguir estas reglas no garantiza el éxito (ya que todos los parches son
> +    sujetos a escrutinio de contenido y estilo), pero en caso de no seguir
> +    dichas reglas, el fracaso es prácticamente garantizado.
> +    Otras excelentes descripciones de cómo crear parches correctamente son:
> +
> +	"The Perfect Patch"
> +		https://www.ozlabs.org/~akpm/stuff/tpp.txt
> +
> +	"Linux kernel patch submission format"
> +		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
> +
> +  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
> +    Este archivo describe la lógica detrás de la decisión consciente de
> +    no tener una API estable dentro del kernel, incluidas cosas como:
> +
> +      - Capas intermedias del subsistema (por compatibilidad?)
> +      - Portabilidad de drivers entre sistemas operativos
> +      - Mitigar el cambio rápido dentro del árbol de fuentes del kernel (o
> +        prevenir cambios rápidos)
> +
> +     Este documento es crucial para comprender la filosofía del desarrollo
> +     de Linux y es muy importante para las personas que se mudan a Linux
> +     tras desarrollar otros sistemas operativos.
> +
> +  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
> +    Si cree que ha encontrado un problema de seguridad en el kernel de
> +    Linux, siga los pasos de este documento para ayudar a notificar a los
> +    desarrolladores del kernel y ayudar a resolver el problema.
> +
> +  :ref:`Documentation/process/management-style.rst <managementstyle>`
> +    Este documento describe cómo operan los maintainers del kernel de Linux
> +    y los valores compartidos detrás de sus metodologías. Esta es una
> +    lectura importante para cualquier persona nueva en el desarrollo del
> +    kernel (o cualquier persona que simplemente sienta curiosidad por
> +    el campo IT), ya que clarifica muchos conceptos erróneos y confusiones
> +    comunes sobre el comportamiento único de los maintainers del kernel.
> +
> +  :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
> +    Este archivo describe las reglas sobre cómo se suceden las versiones
> +    del kernel estable, y qué hacer si desea obtener un cambio en una de
> +    estas publicaciones.
> +
> +  :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
> +    Una lista de documentación externa relativa al desarrollo del kernel.
> +    Por favor consulte esta lista si no encuentra lo que están buscando
> +    dentro de la documentación del kernel.
> +
> +  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
> +    Una buena introducción que describe exactamente qué es un parche y cómo
> +    aplicarlo a las diferentes ramas de desarrollo del kernel.
> +
> +El kernel también tiene una gran cantidad de documentos que pueden ser
> +generados automáticamente desde el propio código fuente o desde
> +ReStructuredText markups (ReST), como este. Esto incluye un descripción
> +completa de la API en el kernel y reglas sobre cómo manejar cerrojos
> +(locking) correctamente.
> +
> +Todos estos documentos se pueden generar como PDF o HTML ejecutando::
> +
> +	make pdfdocs
> +	make htmldocs
> +
> +respectivamente desde el directorio fuente principal del kernel.
> +
> +Los documentos que utilizan el markup ReST se generarán en
> +Documentation/output. También se pueden generar en formatos LaTeX y ePub
> +con::
> +
> +	make latexdocs
> +	make epubdocs
> +
> +Convertirse en un/a desarrollador/a de kernel
> +-------------------------------------------
> +
> +Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
> +el proyecto Linux KernelNewbies:
> +
> +	https://kernelnewbies.org
> +
> +Consiste en una útil lista de correo donde puede preguntar casi cualquier
> +tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en
> +los archivos primero, antes de preguntar algo que ya ha sido respondido en
> +el pasado.) También tiene un canal IRC que puede usar para hacer preguntas
> +en en tiempo real, y una gran cantidad de documentación útil que es útil
> +para ir aprendiendo sobre el desarrollo del kernel de Linux.
> +
> +El sitio web tiene información básica sobre la organización del código,
> +subsistemas, y proyectos actuales (tanto dentro como fuera del árbol).
> +También describe alguna información logística básica, como cómo compilar
> +un kernel y aplicar un parche.
> +
> +Si no sabe por dónde quiere empezar, pero quieres buscar alguna tarea que
> +comenzar a hacer para unirse a la comunidad de desarrollo del kernel,
> +acuda al proyecto Linux Kernel Janitor:
> +
> +	https://kernelnewbies.org/KernelJanitors
> +
> +Es un gran lugar para comenzar. Describe una lista de problemas
> +relativamente simples que deben limpiarse y corregirse dentro del codigo
> +fuente del kernel de Linux árbol de fuentes. Trabajando con los
> +desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos
> +para incluir su parche en el árbol del kernel de Linux, y posiblemente
> +descubrir en la dirección en que trabajar a continuación, si no tiene ya
> +una idea.
> +
> +Antes de realizar cualquier modificación real al código del kernel de
> +Linux, es imperativo entender cómo funciona el código en cuestión. Para
> +este propósito, nada es mejor que leerlo directamente (lo más complicado
> +está bien comentado), tal vez incluso con la ayuda de herramientas
> +especializadas. Una de esas herramientas que se recomienda especialmente
> +es el proyecto Linux Cross-Reference, que es capaz de presentar el código
> +fuente en un formato de página web indexada y autorreferencial. Una
> +excelente puesta al día del repositorio del código del kernel se puede
> +encontrar en:
> +
> +	https://elixir.bootlin.com/
> +
> +El proceso de desarrollo
> +------------------------
> +
> +El proceso de desarrollo del kernel de Linux consiste actualmente de
> +diferentes "branches" (ramas) con muchos distintos subsistemas específicos
> +a cada una de ellas. Las diferentes ramas son:
> +
> +  - El código principal de Linus (mainline tree)
> +  - Varios árboles estables con múltiples major numbers
> +  - Subsistemas específicos
> +  - linux-next, para integración y testing
> +
> +Mainline tree (Árbol principal)
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en
> +https://kernel.org o en su repo.  El proceso de desarrollo es el siguiente:
> +
> +  - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos
> +    semanas, durante este período de tiempo, los maintainers pueden enviar
> +    grandes modificaciones a Linus, por lo general los parches que ya se
> +    han incluido en el linux-next durante unas semanas. La forma preferida
> +    de enviar grandes cambios es usando git (la herramienta de
> +    administración de codigo fuente del kernel, más información al respecto
> +    en https://git-scm.com/), pero los parches simples también son validos.
> +  - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra
> +    en hacer que el kernel nuevo lo más estable ("solido") posible. La
> +    mayoría de los parches en este punto debe arreglar una regresión. Los
> +    errores que siempre han existido no son regresiones, por lo tanto, solo
> +    envíe este tipo de correcciones si son importantes. Tenga en cuenta que
> +    se podría aceptar un controlador (o sistema de archivos) completamente
> +    nuevo después de -rc1 porque no hay riesgo de causar regresiones con
> +    tal cambio, siempre y cuando el cambio sea autónomo y no afecte áreas
> +    fuera del código que se está agregando. git se puede usar para enviar
> +    parches a Linus después de que se lance -rc1, pero los parches también
> +    deben ser enviado a una lista de correo pública para su revisión.
> +  - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git
> +    actual esta en un estado razonablemente sano y adecuado para la prueba.
> +    La meta es lanzar un nuevo kernel -rc cada semana.
> +  - El proceso continúa hasta que el kernel se considera "listo", y esto
> +    puede durar alrededor de 6 semanas.
> +
> +Vale la pena mencionar lo que Andrew Morton escribió en las listas de
> +correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
> +
> +	*"Nadie sabe cuándo se publicara un nuevo kernel, porque esto sucede
> +    de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
> +    una línea temporal preconcebida."*
> +
> +Varios árboles estables con múltiples major numbers
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Los kernels con versiones de 3 partes son kernels estables. Estos contienen
> +correcciones relativamente pequeñas y críticas para problemas de seguridad
> +o importantes regresiones descubiertas para una publicación de código.
> +Cada lanzamiento en una gran serie estable incrementa la tercera parte de
> +la versión número, manteniendo las dos primeras partes iguales.
> +
> +Esta es la rama recomendada para los usuarios que quieren la versión
> +estable más reciente del kernel, y no están interesados ​​en ayudar a probar
> +versiones en desarrollo/experimentales.
> +
> +Los árboles estables son mantenidos por el equipo "estable"
> +<stable@vger.kernel.org>, y se liberan (publican) según lo dicten las
> +necesidades. El período de liberación normal es de aproximadamente dos
> +semanas, pero puede ser más largo si no hay problemas apremiantes. Un
> +problema relacionado con la seguridad, en cambio, puede causar un
> +lanzamiento casi instantáneamente.
> +
> +El archivo :ref:`Documentación/proceso/stable-kernel-rules.rst <stable_kernel_rules>`
> +en el árbol del kernel documenta qué tipos de cambios son aceptables para
> +el árbol estable y cómo funciona el proceso de lanzamiento.
> +
> +Subsistemas específicos
> +~~~~~~~~~~~~~~~~~~~~~~~~
> +Los maintainers de los diversos subsistemas del kernel --- y también muchos
> +desarrolladores de subsistemas del kernel --- exponen su estado actual de
> +desarrollo en repositorios fuente. De esta manera, otros pueden ver lo que
> +está sucediendo en las diferentes áreas del kernel. En áreas donde el
> +desarrollo es rápido, se le puede pedir a un desarrollador que base sus
> +envíos en tal árbol del subsistema del kernel, para evitar conflictos entre
> +este y otros trabajos ya en curso.
> +
> +La mayoría de estos repositorios son árboles git, pero también hay otros
> +SCM en uso, o colas de parches que se publican como series quilt. Las
> +direcciones de estos repositorios de subsistemas se enumeran en el archivo
> +MAINTAINERS. Muchos de estos se pueden ver en https://git.kernel.org/.
> +
> +Antes de que un parche propuesto se incluya con dicho árbol de subsistemas,
> +es sujeto a revisión, que ocurre principalmente en las listas de correo
> +(ver la sección respectiva a continuación). Para varios subsistemas del
> +kernel, esta revisión se rastrea con la herramienta patchwork. Patchwork
> +ofrece una interfaz web que muestra publicaciones de parches, cualquier
> +comentario sobre un parche o revisiones a él, y los maintainers pueden
> +marcar los parches como en revisión, aceptado, o rechazado. La mayoría de
> +estos sitios de trabajo de parches se enumeran en
> +
> +https://patchwork.kernel.org/.
> +
> +linux-next, para integración y testing
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Antes de que las actualizaciones de los árboles de subsistemas se combinen
> +con el árbol principal, necesitan probar su integración. Para ello, existe
> +un repositorio especial de pruebas en el que se encuentran casi todos los
> +árboles de subsistema, actualizado casi a diario:
> +
> +	https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
> +
> +De esta manera, linux-next ofrece una perspectiva resumida de lo que se
> +espera que entre en el kernel principal en el próximo período de "merge"
> +(fusión de codigo). Los testers aventureros son bienvenidos a probar
> +linux-next en ejecución.
> +
> +Reportar bugs
> +-------------
> +
> +El archivo 'Documentación/admin-guide/reporting-issues.rst' en el
> +directorio principal del kernel describe cómo informar un posible bug del
> +kernel y detalles sobre qué tipo de información necesitan los
> +desarrolladores del kernel para ayudar a rastrear la fuente del problema.
> +
> +Gestión de informes de bugs
> +------------------------------
> +
> +Una de las mejores formas de poner en práctica sus habilidades de hacking
> +es arreglando errores reportados por otras personas. No solo ayudará a
> +hacer el kernel más estable, también aprenderá a solucionar problemas del
> +mundo real y mejora sus habilidades, y otros desarrolladores se darán
> +cuenta de tu presencia. La corrección de errores es una de las mejores
> +formas de ganar méritos entre desarrolladores, porque no a muchas personas
> +les gusta perder el tiempo arreglando los errores de otras personas.
> +
> +Para trabajar en informes de errores ya reportados, busque un subsistema
> +que le interese. Verifique el archivo MAINTAINERS donde se informan los
> +errores de ese subsistema; con frecuencia será una lista de correo, rara
> +vez un rastreador de errores (bugtracker). Busque en los archivos de dicho
> +lugar para informes recientes y ayude donde lo crea conveniente. También es
> +posible que desee revisar https://bugzilla.kernel.org para informes de
> +errores; solo un puñado de subsistemas del kernel lo emplean activamente
> +para informar o rastrear; sin embargo, todos los errores para todo el kernel
> +se archivan allí.
> +
> +Listas de correo
> +-----------------
> +
> +Como se explica en algunos de los documentos anteriores, la mayoría de
> +desarrolladores del kernel participan en la lista de correo del kernel de
> +Linux. Detalles sobre cómo para suscribirse y darse de baja de la lista se
> +pueden encontrar en:
> +
> +	http://vger.kernel.org/vger-lists.html#linux-kernel
> +
> +Existen archivos de la lista de correo en la web en muchos lugares
> +distintos. Utilice un motor de búsqueda para encontrar estos archivos. Por
> +ejemplo:
> +
> +	http://dir.gmane.org/gmane.linux.kernel
> +
> +Es muy recomendable que busque en los archivos sobre el tema que desea
> +tratar, antes de publicarlo en la lista. Un montón de cosas ya discutidas
> +en detalle solo se registran en los archivos de la lista de correo.
> +
> +La mayoría de los subsistemas individuales del kernel también tienen sus
> +propias lista de correo donde hacen sus esfuerzos de desarrollo. Revise el
> +archivo MAINTAINERS para obtener referencias de lo que estas listas para
> +los diferentes grupos.
> +
> +Muchas de las listas están alojadas en kernel.org. La información sobre
> +estas puede ser encontrada en:
> +
> +	http://vger.kernel.org/vger-lists.html
> +
> +Recuerde mantener buenos hábitos de comportamiento al usar las listas.
> +Aunque un poco cursi, la siguiente URL tiene algunas pautas simples para
> +interactuar con la lista (o cualquier lista):
> +
> +	http://www.albion.com/netiquette/
> +
> +Si varias personas responden a su correo, el CC (lista de destinatarios)
> +puede hacerse bastante grande. No elimine a nadie de la lista CC: sin una
> +buena razón, o no responda solo a la dirección de la lista. Acostúmbrese
> +a recibir correos dos veces, una del remitente y otra de la lista, y no
> +intente ajustar esto agregando encabezados de correo astutos, a la gente no
> +le gustará.
> +
> +Recuerde mantener intacto el contexto y la atribución de sus respuestas,
> +mantenga las líneas "El hacker John Kernel escribió ...:" en la parte
> +superior de su respuesta, y agregue sus declaraciones entre las secciones
> +individuales citadas en lugar de escribiendo en la parte superior del
> +correo electrónico.
> +
> +Si incluye parches en su correo, asegúrese de que sean texto legible sin
> +formato como se indica en :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
> +Los desarrolladores del kernel no quieren lidiar con archivos adjuntos o
> +parches comprimidos; y pueden querer comentar líneas individuales de su
> +parche, que funciona sólo de esa manera. Asegúrese de emplear un programa
> +de correo que no altere los espacios ni los tabuladores. Una buena primera
> +prueba es enviarse el correo a usted mismo, e intentar aplicar su
> +propio parche. Si eso no funciona, arregle su programa de correo o
> +reemplace hasta que funcione.
> +
> +Sobretodo, recuerde de ser respetuoso con otros subscriptores.
> +
> +Colaborando con la comunidad
> +----------------------------
> +
> +El objetivo de la comunidad del kernel es proporcionar el mejor kernel
> +posible. Cuando envíe un parche para su aceptación, se revisará en sus
> +méritos técnicos solamente. Entonces, ¿qué deberías ser?
> +
> +  - criticas
> +  - comentarios
> +  - peticiones de cambios
> +  - peticiones de justificaciones
> +  - silencio
> +
> +Recuerde, esto es parte de introducir su parche en el kernel. Tiene que ser
> +capaz de recibir críticas y comentarios sobre sus parches, evaluar
> +a nivel técnico y re-elaborar sus parches o proporcionar razonamiento claro
> +y conciso de por qué no se deben hacer tales cambios. Si no hay respuestas
> +a su publicación, espere unos días e intente de nuevo, a veces las cosas se
> +pierden dado el gran volumen.
> +
> +¿Qué no debería hacer?
> +
> +  - esperar ue su parche se acepte sin preguntas
> +  - actuar de forma defensiva
> +  - ignorar comentarios
> +  - enviar el parche de nuevo, sin haber aplicados los cambios pertinentes
> +
> +En una comunidad que busca la mejor solución técnica posible, siempre habrá
> +diferentes opiniones sobre lo beneficioso que es un parche. Tiene que ser
> +cooperativo y estar dispuesto a adaptar su idea para que encaje dentro
> +del kernel, o al menos esté dispuesto a demostrar que su idea vale la pena.
> +Recuerea, estar equivocado es aceptable siempre y cuando estés dispuesto a
> +trabajar hacia una solución que sea correcta.
> +
> +Es normal que las respuestas a su primer parche sean simplemente una lista
> +de una docena de cosas que debe corregir. Esto **no** implica que su
> +parche no será aceptado, y **no** es personal. Simplemente corrija todos
> +los problemas planteados en su parche, y envié otra vez.
> +
> +Diferencias entre la comunidad kernel y las estructuras corporativas
> +--------------------------------------------------------------------
> +
> +La comunidad del kernel funciona de manera diferente a la mayoría de los
> +entornos de desarrollo tradicionales en empresas. Aquí hay una lista de
> +cosas que puede intentar hacer para evitar problemas:
> +
> +  Cosas buenas que decir respecto a los cambios propuestos:
> +
> +    - "Esto arregla múltiples problemas."
> +    - "Esto elimina 2000 lineas de código."
> +    - "Aquí hay un parche que explica lo que intento describir."
> +    - "Lo he testeado en 5 arquitecturas distintas..."
> +    - "Aquí hay una serie de parches menores que..."
> +    - "Esto mejora el rendimiento en maquinas típicas..."
> +
> +  Cosas negativas que debe evitar decir:
> +
> +    - "Lo hicimos asi en AIX/ptx/Solaris, de modo que debe ser bueno..."
> +    - "LLevo haciendo esto 20 años, de modo que..."
> +    - "Esto lo necesita mi empresa para ganar dinero"
> +    - "Esto es para la linea de nuestros productos Enterprise"
> +    - "Aquí esta el documento de 1000 paginas describiendo mi idea"
> +    - "Llevo 6 meses trabajando en esto..."
> +    - "Aquí esta un parche de 5000 lineas que..."
> +    - "He rescrito todo el desastre actual, y aqui esta..."
> +    - "Tengo un deadline, y este parche debe aplicarse ahora."
> +
> +Otra forma en que la comunidad del kernel es diferente a la mayoría de los
> +entornos de trabajo tradicionales en ingeniería de software, es la
> +naturaleza sin rostro de interacción. Una de las ventajas de utilizar el
> +correo electrónico y el IRC como formas principales de comunicación es la
> +no discriminación por motivos de género o raza. El entorno de trabajo del
> +kernel de Linux acepta a mujeres y minorías porque todo lo que eres es una
> +dirección de correo electrónico. El aspecto internacional también ayuda a
> +nivelar el campo de juego porque no puede adivinar el género basado en
> +el nombre de una persona. Un hombre puede llamarse Andrea y una mujer puede
> +llamarse Pat. La mayoría de las mujeres que han trabajado en el kernel de
> +Linux y han expresado una opinión han tenido experiencias positivas.
> +
> +La barrera del idioma puede causar problemas a algunas personas que no se
> +sientes cómodas con el inglés. Un buen dominio del idioma puede ser
> +necesario para transmitir ideas correctamente en las listas de correo, por
> +lo que le recomendamos que revise sus correos electrónicos para asegurarse
> +de que tengan sentido en inglés antes de enviarlos.
> +
> +Divida sus cambios
> +---------------------
> +
> +La comunidad del kernel de Linux no acepta con gusto grandes fragmentos de
> +código, sobretodo a la vez. Los cambios deben introducirse correctamente,
> +discutidos y divididos en pequeñas porciones individuales. Esto es casi
> +exactamente lo contrario de lo que las empresas están acostumbradas a hacer.
> +Su propuesta también debe introducirse muy temprano en el proceso de
> +desarrollo, de modo que pueda recibir comentarios sobre lo que está
> +haciendo. También deje que la comunidad sienta que está trabajando con
> +ellos, y no simplemente usándolos como un vertedero para su función. Sin
> +embargo, no envíe 50 correos electrónicos a una vez a una lista de correo,
> +su serie de parches debe casi siempre ser más pequeña que eso.
> +
> +Las razones para dividir las cosas son las siguientes:
> +
> +1) Los cambios pequeños aumentan la probabilidad de que sus parches sean
> +   aplicados, ya que no requieren mucho tiempo o esfuerzo para verificar su
> +   exactitud. Un parche de 5 líneas puede ser aplicado por un maintainer
> +   con apenas una segunda mirada. Sin embargo, un parche de 500 líneas
> +   puede tardar horas en ser revisado en términos de corrección (el tiempo
> +   que toma es exponencialmente proporcional al tamaño del parche, o algo
> +   así).
> +
> +   Los parches pequeños también facilitan la depuración cuando algo falla.
> +   Es mucho más fácil retirar los parches uno por uno que diseccionar un
> +   parche muy grande después de haber sido aplicado (y roto alguna cosa).
> +
> +2) Es importante no solo enviar pequeños parches, sino también reescribir
> +   y simplificar (o simplemente reordenar) los parches antes de enviarlos.
> +
> +Esta es una analogía del desarrollador del kernel Al Viro (traducida):
> +
> +	*"Piense en un maestro que califica la tarea de un estudiante de
> +	matemáticas. El maestro no quiere ver los intentos y errores del
> +	estudiante antes de que se les ocurriera la solución. Quiere ver la
> +	respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca
> +	presentaría su trabajo intermedio antes de tener la solución final.*
> +
> +	* Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
> +	revisores no quieren ver el proceso de pensamiento detrás de la solución
> +	al problema que se está resolviendo. Quieren ver un solución simple y
> +	elegante."*
> +
> +Puede resultar un reto mantener el equilibrio entre presentar una solución
> +elegante y trabajar junto a la comunidad, discutiendo su trabajo inacabado.
> +Por lo tanto, es bueno comenzar temprano en el proceso para obtener
> +"feedback" y mejorar su trabajo, pero también mantenga sus cambios en
> +pequeños trozos que pueden ser aceptados, incluso cuando toda su labor no
> +está listo para inclusión en un momento dado.
> +
> +También tenga en cuenta que no es aceptable enviar parches para su
> +inclusión que están sin terminar y serán "arreglados más tarde".
> +
> +Justifique sus cambios
> +----------------------
> +
> +Además de dividir sus parches, es muy importante que deje a la comunidad de
> +Linux sabe por qué deberían agregar este cambio. Nuevas características
> +debe justificarse como necesarias y útiles.
> +
> +Documente sus cambios
> +--------------------
> +
> +Cuando envíe sus parches, preste especial atención a lo que dice en el
> +texto de su correo electrónico. Esta información se convertirá en el
> +ChangeLog del parche, y se conservará para que todos la vean, todo el
> +tiempo. Debe describir el parche por completo y contener:
> +
> +  - por que los cambios son necesarios
> +  - el diseño general de su propuesta
> +  - detalles de implementación
> +  - resultados de sus experimentos
> +
> +Para obtener más detalles sobre cómo debería quedar todo esto, consulte la
> +sección ChangeLog del documento:
> +
> +  "The Perfect Patch"
> +      https://www.ozlabs.org/~akpm/stuff/tpp.txt
> +
> +Todas estas cuestiones son a veces son muy difíciles de conseguir. Puede
> +llevar años perfeccionar estas prácticas (si es que lo hace). Es un proceso
> +continuo de mejora que requiere mucha paciencia y determinación. Pero no se
> +rinda, es posible. Muchos lo han hecho antes, y cada uno tuvo que comenzar
> +exactamente donde está usted ahora.
> +
> +
> +----------
> +
> +Gracias a Paolo Ciarrocchi que permitió que la sección "Development Process"
> +se basara en el texto que había escrito (https://lwn.net/Articles/94386/),
> +y a Randy Dunlap y Gerrit Huizenga por algunas de la lista de cosas que
> +debes y no debes decir. También gracias a Pat Mochel, Hanna Linder, Randy
> +Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook,
> +Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk,
> +Keri Harris, Frans Pop, David A. Wheeler, Junio ​​Hamano, Michael Kerrisk y
> +Alex Shepard por su revisión, comentarios y contribuciones. Sin su ayuda,
> +este documento no hubiera sido posible.
> +
> +Maintainer: Greg Kroah-Hartman <greg@kroah.com>

kernel test robot have already reported documentation warnings at [1],
so I have applied the fixup:

---- >8 ----

diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
index 4cf8fa6b9f7c2e..0c072b9a69df30 100644
--- a/Documentation/translations/sp_SP/howto.rst
+++ b/Documentation/translations/sp_SP/howto.rst
@@ -183,7 +183,7 @@ con::
 	make epubdocs
 
 Convertirse en un/a desarrollador/a de kernel
--------------------------------------------
+---------------------------------------------
 
 Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
 el proyecto Linux KernelNewbies:
@@ -274,8 +274,8 @@ Vale la pena mencionar lo que Andrew Morton escribió en las listas de
 correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
 
 	*"Nadie sabe cuándo se publicara un nuevo kernel, porque esto sucede
-    de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
-    una línea temporal preconcebida."*
+        de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
+        una línea temporal preconcebida."*
 
 Varios árboles estables con múltiples major numbers
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -556,7 +556,7 @@ Esta es una analogía del desarrollador del kernel Al Viro (traducida):
 	respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca
 	presentaría su trabajo intermedio antes de tener la solución final.*
 
-	* Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
+	*Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
 	revisores no quieren ver el proceso de pensamiento detrás de la solución
 	al problema que se está resolviendo. Quieren ver un solución simple y
 	elegante."*
@@ -579,7 +579,7 @@ Linux sabe por qué deberían agregar este cambio. Nuevas características
 debe justificarse como necesarias y útiles.
 
 Documente sus cambios
---------------------
+---------------------
 
 Cuando envíe sus parches, preste especial atención a lo que dice en el
 texto de su correo electrónico. Esta información se convertirá en el

Muchas gracias (thanks very much).

[1]: https://lore.kernel.org/linux-doc/202210141348.7UGXRUp8-lkp@intel.com/
-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 2/2] Documentation: Add HOWTO Spanish translation into rst based build system

[Carlos Bilbao]

On 10/14/22 04:21, Bagas Sanjaya wrote:

> ¡Hola Carlos! Gracias for start writing Spanish translations. However,
> the patch can be improved, see below.
Hola Bagas, thanks for your feedback :)
>
> On Thu, Oct 13, 2022 at 01:48:16PM -0500, Carlos Bilbao wrote:
>> This commit adds Spanish translation of HOWTO document into rst based
>> documentation build system.
>>
> Better say "Translate HOWTO document into Spanish".
So, for the commit message here I just replicated what prior folks did,
see:

For Japanese:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/translations/ja_JP?h=v6.0&id=f012733894d36ff687862e9cd3b02ee980c61416

For Korean:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/translations/ko_KR/howto.rst?h=v6.0&id=ba42c574fc8b803ec206785b7b91325c05810422

I think I will leave that commit message, it is slightly more informative
than "Translate HOWTO document into Spanish".

>
>> Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
>> ---
>>   Documentation/translations/sp_SP/howto.rst | 619 +++++++++++++++++++++
>>   Documentation/translations/sp_SP/index.rst |   7 +
>>   2 files changed, 626 insertions(+)
>>   create mode 100644 Documentation/translations/sp_SP/howto.rst
>>
>> diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
>> new file mode 100644
>> index 000000000000..4cf8fa6b9f7c
>> --- /dev/null
>> +++ b/Documentation/translations/sp_SP/howto.rst
>> @@ -0,0 +1,619 @@
>> +.. include:: ./disclaimer-sp.rst
>> +
>> +:Original: :ref:`Documentation/process/howto.rst <process_howto>`
>> +:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
>> +
>> +.. _sp_process_howto:
>> +
>> +Cómo participar en el desarrollo del kernel de Linux
>> +====================================================
>> +
>> +Este documento es el principal punto de partida. Contiene instrucciones
>> +sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
>> +trabajar con el y en su desarrollo. El documento no tratará ningún aspecto
>> +técnico relacionado con la programación del kernel, pero le ayudará
>> +guiándole por el camino correcto.
>> +
>> +Si algo en este documento quedara obsoleto, envíe parches al maintainer de
>> +este archivo, que se encuentra en la parte superior del documento.
>> +
>> +Introducción
>> +------------
>> +¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
>> +kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
>> +Linux para este dispositivo." El objetivo de este documento en enseñarle
>> +todo cuanto necesita para conseguir esto, describiendo el proceso por el
>> +que debe pasar, y con indicaciones de como trabajar con la comunidad.
>> +También trata de explicar las razones por las cuales la comunidad trabaja
>> +de la forma en que lo hace.
>> +
>> +El kernel esta principalmente escrito en C, con algunas partes que son
>> +dependientes de la arquitectura en ensamblador. Un buen conocimiento de C
>> +es necesario para desarrollar en el kernel. Lenguaje ensamblador (en
>> +cualquier arquitectura) no es necesario excepto que planee realizar
>> +desarrollo de bajo nivel para dicha arquitectura. Aunque no es un perfecto
>> +sustituto para una educación sólida en C y/o años de experiencia, los
>> +siguientes libros sirven, como mínimo, como referencia:
>> +
>> +- "The C Programming Language" de Kernighan e Ritchie [Prentice Hall]
>> +- "Practical C Programming" de Steve Oualline [O'Reilly]
>> +- "C:  A Reference Manual" de Harbison and Steele [Prentice Hall]
>> +
>> +El kernel está escrito usando GNU C y la cadena de herramientas GNU. Si
>> +bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que
>> +no aparecen en dicho estándar. El kernel usa un C independiente de entorno,
>> +sin depender de la biblioteca C estándar, por lo que algunas partes del
>> +estándar C no son compatibles. Divisiones de long long arbitrarios o
>> +de coma flotante no son permitidas. En ocasiones, puede ser difícil de
>> +entender las suposiciones que el kernel hace respecto a la cadena de
>> +herramientas y las extensiones que usa, y desafortunadamente no hay
>> +referencia definitiva para estos. Consulte las páginas de información de
>> +gcc (`info gcc`) para obtener información al respecto.
>> +
>> +Recuerde que está tratando de aprender a trabajar con una comunidad de
>> +desarrollo existente. Es un grupo diverso de personas, con altos estándares
>> +de codificación, estilo y procedimiento. Estas normas han sido creadas a lo
>> +largo del tiempo en función de lo que se ha encontrado que funciona mejor
>> +para un equipo tan grande y geográficamente disperso. Trate de aprender
>> +tanto como le sea posible acerca de estos estándares antes de tiempo, ya
>> +que están bien documentados; no espere que la gente se adapte a usted o a
>> +su forma de ser de hacer las cosas.
>> +
>> +Cuestiones legales
>> +------------------
>> +El código fuente del kernel de Linux se publica bajo licencia GPL. Por
>> +favor, revise el archivo COPYING, presente en la carpeta principal del
>> +fuente, para detalles de la licencia. Si tiene alguna otra pregunta
>> +sobre licencias, contacte a un abogado, no pregunte en listas de discusión
>> +del kernel de Linux. Las personas en estas listas no son abogadas, y no
>> +debe confiar en sus opiniones en materia legal.
>> +
>> +Para preguntas y respuestas más frecuentes sobre la licencia GPL, consulte:
>> +
>> +	https://www.gnu.org/licenses/gpl-faq.html
>> +
>> +Documentacion
>> +--------------
>> +El código fuente del kernel de Linux tiene una gran variedad de documentos
>> +que son increíblemente valiosos para aprender a interactuar con la
>> +comunidad del kernel. Cuando se agregan nuevas funciones al kernel, se
>> +recomienda que se incluyan nuevos archivos de documentación que expliquen
>> +cómo usar la función. Cuando un cambio en el kernel hace que la interfaz
>> +que el kernel expone espacio de usuario cambie, se recomienda que envíe la
>> +información o un parche en las páginas del manual que expliquen el cambio
>> +a mtk.manpages@gmail.com, y CC la lista linux-api@vger.kernel.org.
>> +
>> +Esta es la lista de archivos que están en el código fuente del kernel y son
>> +de obligada lectura:
>> +
>> +  :ref:`Documentation/admin-guide/README.rst <readme>`
>> +    Este archivo ofrece una breve descripción del kernel de Linux y
>> +    describe lo que es necesario hacer para configurar y compilar el
>> +    kernel. Quienes sean nuevos en el kernel deben comenzar aquí.
>> +
>> +  :ref:`Documentation/process/changes.rst <changes>`
>> +    Este archivo proporciona una lista de los niveles mínimos de varios
>> +    paquetes que son necesarios para construir y ejecutar el kernel
>> +    exitosamente.
>> +
>> +  :ref:`Documentation/process/coding-style.rst <codingstyle>`
>> +    Esto describe el estilo de código del kernel de Linux y algunas de los
>> +    razones detrás de esto. Se espera que todo el código nuevo siga las
>> +    directrices de este documento. La mayoría de los maintainers solo
>> +    aceptarán parches si se siguen estas reglas, y muchas personas solo
>> +    revisan el código si tiene el estilo adecuado.
>> +
>> +  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
>> +    Este archivo describe en gran detalle cómo crear con éxito y enviar un
>> +    parche, que incluye (pero no se limita a):
>> +
>> +       - Contenidos del correo electrónico (email)
>> +       - Formato del email
>> +       - A quien se debe enviar
>> +
>> +    Seguir estas reglas no garantiza el éxito (ya que todos los parches son
>> +    sujetos a escrutinio de contenido y estilo), pero en caso de no seguir
>> +    dichas reglas, el fracaso es prácticamente garantizado.
>> +    Otras excelentes descripciones de cómo crear parches correctamente son:
>> +
>> +	"The Perfect Patch"
>> +		https://www.ozlabs.org/~akpm/stuff/tpp.txt
>> +
>> +	"Linux kernel patch submission format"
>> +		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
>> +
>> +  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
>> +    Este archivo describe la lógica detrás de la decisión consciente de
>> +    no tener una API estable dentro del kernel, incluidas cosas como:
>> +
>> +      - Capas intermedias del subsistema (por compatibilidad?)
>> +      - Portabilidad de drivers entre sistemas operativos
>> +      - Mitigar el cambio rápido dentro del árbol de fuentes del kernel (o
>> +        prevenir cambios rápidos)
>> +
>> +     Este documento es crucial para comprender la filosofía del desarrollo
>> +     de Linux y es muy importante para las personas que se mudan a Linux
>> +     tras desarrollar otros sistemas operativos.
>> +
>> +  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
>> +    Si cree que ha encontrado un problema de seguridad en el kernel de
>> +    Linux, siga los pasos de este documento para ayudar a notificar a los
>> +    desarrolladores del kernel y ayudar a resolver el problema.
>> +
>> +  :ref:`Documentation/process/management-style.rst <managementstyle>`
>> +    Este documento describe cómo operan los maintainers del kernel de Linux
>> +    y los valores compartidos detrás de sus metodologías. Esta es una
>> +    lectura importante para cualquier persona nueva en el desarrollo del
>> +    kernel (o cualquier persona que simplemente sienta curiosidad por
>> +    el campo IT), ya que clarifica muchos conceptos erróneos y confusiones
>> +    comunes sobre el comportamiento único de los maintainers del kernel.
>> +
>> +  :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
>> +    Este archivo describe las reglas sobre cómo se suceden las versiones
>> +    del kernel estable, y qué hacer si desea obtener un cambio en una de
>> +    estas publicaciones.
>> +
>> +  :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
>> +    Una lista de documentación externa relativa al desarrollo del kernel.
>> +    Por favor consulte esta lista si no encuentra lo que están buscando
>> +    dentro de la documentación del kernel.
>> +
>> +  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
>> +    Una buena introducción que describe exactamente qué es un parche y cómo
>> +    aplicarlo a las diferentes ramas de desarrollo del kernel.
>> +
>> +El kernel también tiene una gran cantidad de documentos que pueden ser
>> +generados automáticamente desde el propio código fuente o desde
>> +ReStructuredText markups (ReST), como este. Esto incluye un descripción
>> +completa de la API en el kernel y reglas sobre cómo manejar cerrojos
>> +(locking) correctamente.
>> +
>> +Todos estos documentos se pueden generar como PDF o HTML ejecutando::
>> +
>> +	make pdfdocs
>> +	make htmldocs
>> +
>> +respectivamente desde el directorio fuente principal del kernel.
>> +
>> +Los documentos que utilizan el markup ReST se generarán en
>> +Documentation/output. También se pueden generar en formatos LaTeX y ePub
>> +con::
>> +
>> +	make latexdocs
>> +	make epubdocs
>> +
>> +Convertirse en un/a desarrollador/a de kernel
>> +-------------------------------------------
>> +
>> +Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
>> +el proyecto Linux KernelNewbies:
>> +
>> +	https://kernelnewbies.org
>> +
>> +Consiste en una útil lista de correo donde puede preguntar casi cualquier
>> +tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en
>> +los archivos primero, antes de preguntar algo que ya ha sido respondido en
>> +el pasado.) También tiene un canal IRC que puede usar para hacer preguntas
>> +en en tiempo real, y una gran cantidad de documentación útil que es útil
>> +para ir aprendiendo sobre el desarrollo del kernel de Linux.
>> +
>> +El sitio web tiene información básica sobre la organización del código,
>> +subsistemas, y proyectos actuales (tanto dentro como fuera del árbol).
>> +También describe alguna información logística básica, como cómo compilar
>> +un kernel y aplicar un parche.
>> +
>> +Si no sabe por dónde quiere empezar, pero quieres buscar alguna tarea que
>> +comenzar a hacer para unirse a la comunidad de desarrollo del kernel,
>> +acuda al proyecto Linux Kernel Janitor:
>> +
>> +	https://kernelnewbies.org/KernelJanitors
>> +
>> +Es un gran lugar para comenzar. Describe una lista de problemas
>> +relativamente simples que deben limpiarse y corregirse dentro del codigo
>> +fuente del kernel de Linux árbol de fuentes. Trabajando con los
>> +desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos
>> +para incluir su parche en el árbol del kernel de Linux, y posiblemente
>> +descubrir en la dirección en que trabajar a continuación, si no tiene ya
>> +una idea.
>> +
>> +Antes de realizar cualquier modificación real al código del kernel de
>> +Linux, es imperativo entender cómo funciona el código en cuestión. Para
>> +este propósito, nada es mejor que leerlo directamente (lo más complicado
>> +está bien comentado), tal vez incluso con la ayuda de herramientas
>> +especializadas. Una de esas herramientas que se recomienda especialmente
>> +es el proyecto Linux Cross-Reference, que es capaz de presentar el código
>> +fuente en un formato de página web indexada y autorreferencial. Una
>> +excelente puesta al día del repositorio del código del kernel se puede
>> +encontrar en:
>> +
>> +	https://elixir.bootlin.com/
>> +
>> +El proceso de desarrollo
>> +------------------------
>> +
>> +El proceso de desarrollo del kernel de Linux consiste actualmente de
>> +diferentes "branches" (ramas) con muchos distintos subsistemas específicos
>> +a cada una de ellas. Las diferentes ramas son:
>> +
>> +  - El código principal de Linus (mainline tree)
>> +  - Varios árboles estables con múltiples major numbers
>> +  - Subsistemas específicos
>> +  - linux-next, para integración y testing
>> +
>> +Mainline tree (Árbol principal)
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en
>> +https://kernel.org o en su repo.  El proceso de desarrollo es el siguiente:
>> +
>> +  - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos
>> +    semanas, durante este período de tiempo, los maintainers pueden enviar
>> +    grandes modificaciones a Linus, por lo general los parches que ya se
>> +    han incluido en el linux-next durante unas semanas. La forma preferida
>> +    de enviar grandes cambios es usando git (la herramienta de
>> +    administración de codigo fuente del kernel, más información al respecto
>> +    en https://git-scm.com/), pero los parches simples también son validos.
>> +  - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra
>> +    en hacer que el kernel nuevo lo más estable ("solido") posible. La
>> +    mayoría de los parches en este punto debe arreglar una regresión. Los
>> +    errores que siempre han existido no son regresiones, por lo tanto, solo
>> +    envíe este tipo de correcciones si son importantes. Tenga en cuenta que
>> +    se podría aceptar un controlador (o sistema de archivos) completamente
>> +    nuevo después de -rc1 porque no hay riesgo de causar regresiones con
>> +    tal cambio, siempre y cuando el cambio sea autónomo y no afecte áreas
>> +    fuera del código que se está agregando. git se puede usar para enviar
>> +    parches a Linus después de que se lance -rc1, pero los parches también
>> +    deben ser enviado a una lista de correo pública para su revisión.
>> +  - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git
>> +    actual esta en un estado razonablemente sano y adecuado para la prueba.
>> +    La meta es lanzar un nuevo kernel -rc cada semana.
>> +  - El proceso continúa hasta que el kernel se considera "listo", y esto
>> +    puede durar alrededor de 6 semanas.
>> +
>> +Vale la pena mencionar lo que Andrew Morton escribió en las listas de
>> +correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
>> +
>> +	*"Nadie sabe cuándo se publicara un nuevo kernel, porque esto sucede
>> +    de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
>> +    una línea temporal preconcebida."*
>> +
>> +Varios árboles estables con múltiples major numbers
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +Los kernels con versiones de 3 partes son kernels estables. Estos contienen
>> +correcciones relativamente pequeñas y críticas para problemas de seguridad
>> +o importantes regresiones descubiertas para una publicación de código.
>> +Cada lanzamiento en una gran serie estable incrementa la tercera parte de
>> +la versión número, manteniendo las dos primeras partes iguales.
>> +
>> +Esta es la rama recomendada para los usuarios que quieren la versión
>> +estable más reciente del kernel, y no están interesados ​​en ayudar a probar
>> +versiones en desarrollo/experimentales.
>> +
>> +Los árboles estables son mantenidos por el equipo "estable"
>> +<stable@vger.kernel.org>, y se liberan (publican) según lo dicten las
>> +necesidades. El período de liberación normal es de aproximadamente dos
>> +semanas, pero puede ser más largo si no hay problemas apremiantes. Un
>> +problema relacionado con la seguridad, en cambio, puede causar un
>> +lanzamiento casi instantáneamente.
>> +
>> +El archivo :ref:`Documentación/proceso/stable-kernel-rules.rst <stable_kernel_rules>`
>> +en el árbol del kernel documenta qué tipos de cambios son aceptables para
>> +el árbol estable y cómo funciona el proceso de lanzamiento.
>> +
>> +Subsistemas específicos
>> +~~~~~~~~~~~~~~~~~~~~~~~~
>> +Los maintainers de los diversos subsistemas del kernel --- y también muchos
>> +desarrolladores de subsistemas del kernel --- exponen su estado actual de
>> +desarrollo en repositorios fuente. De esta manera, otros pueden ver lo que
>> +está sucediendo en las diferentes áreas del kernel. En áreas donde el
>> +desarrollo es rápido, se le puede pedir a un desarrollador que base sus
>> +envíos en tal árbol del subsistema del kernel, para evitar conflictos entre
>> +este y otros trabajos ya en curso.
>> +
>> +La mayoría de estos repositorios son árboles git, pero también hay otros
>> +SCM en uso, o colas de parches que se publican como series quilt. Las
>> +direcciones de estos repositorios de subsistemas se enumeran en el archivo
>> +MAINTAINERS. Muchos de estos se pueden ver en https://git.kernel.org/.
>> +
>> +Antes de que un parche propuesto se incluya con dicho árbol de subsistemas,
>> +es sujeto a revisión, que ocurre principalmente en las listas de correo
>> +(ver la sección respectiva a continuación). Para varios subsistemas del
>> +kernel, esta revisión se rastrea con la herramienta patchwork. Patchwork
>> +ofrece una interfaz web que muestra publicaciones de parches, cualquier
>> +comentario sobre un parche o revisiones a él, y los maintainers pueden
>> +marcar los parches como en revisión, aceptado, o rechazado. La mayoría de
>> +estos sitios de trabajo de parches se enumeran en
>> +
>> +https://patchwork.kernel.org/.
>> +
>> +linux-next, para integración y testing
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +Antes de que las actualizaciones de los árboles de subsistemas se combinen
>> +con el árbol principal, necesitan probar su integración. Para ello, existe
>> +un repositorio especial de pruebas en el que se encuentran casi todos los
>> +árboles de subsistema, actualizado casi a diario:
>> +
>> +	https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
>> +
>> +De esta manera, linux-next ofrece una perspectiva resumida de lo que se
>> +espera que entre en el kernel principal en el próximo período de "merge"
>> +(fusión de codigo). Los testers aventureros son bienvenidos a probar
>> +linux-next en ejecución.
>> +
>> +Reportar bugs
>> +-------------
>> +
>> +El archivo 'Documentación/admin-guide/reporting-issues.rst' en el
>> +directorio principal del kernel describe cómo informar un posible bug del
>> +kernel y detalles sobre qué tipo de información necesitan los
>> +desarrolladores del kernel para ayudar a rastrear la fuente del problema.
>> +
>> +Gestión de informes de bugs
>> +------------------------------
>> +
>> +Una de las mejores formas de poner en práctica sus habilidades de hacking
>> +es arreglando errores reportados por otras personas. No solo ayudará a
>> +hacer el kernel más estable, también aprenderá a solucionar problemas del
>> +mundo real y mejora sus habilidades, y otros desarrolladores se darán
>> +cuenta de tu presencia. La corrección de errores es una de las mejores
>> +formas de ganar méritos entre desarrolladores, porque no a muchas personas
>> +les gusta perder el tiempo arreglando los errores de otras personas.
>> +
>> +Para trabajar en informes de errores ya reportados, busque un subsistema
>> +que le interese. Verifique el archivo MAINTAINERS donde se informan los
>> +errores de ese subsistema; con frecuencia será una lista de correo, rara
>> +vez un rastreador de errores (bugtracker). Busque en los archivos de dicho
>> +lugar para informes recientes y ayude donde lo crea conveniente. También es
>> +posible que desee revisar https://bugzilla.kernel.org para informes de
>> +errores; solo un puñado de subsistemas del kernel lo emplean activamente
>> +para informar o rastrear; sin embargo, todos los errores para todo el kernel
>> +se archivan allí.
>> +
>> +Listas de correo
>> +-----------------
>> +
>> +Como se explica en algunos de los documentos anteriores, la mayoría de
>> +desarrolladores del kernel participan en la lista de correo del kernel de
>> +Linux. Detalles sobre cómo para suscribirse y darse de baja de la lista se
>> +pueden encontrar en:
>> +
>> +	http://vger.kernel.org/vger-lists.html#linux-kernel
>> +
>> +Existen archivos de la lista de correo en la web en muchos lugares
>> +distintos. Utilice un motor de búsqueda para encontrar estos archivos. Por
>> +ejemplo:
>> +
>> +	http://dir.gmane.org/gmane.linux.kernel
>> +
>> +Es muy recomendable que busque en los archivos sobre el tema que desea
>> +tratar, antes de publicarlo en la lista. Un montón de cosas ya discutidas
>> +en detalle solo se registran en los archivos de la lista de correo.
>> +
>> +La mayoría de los subsistemas individuales del kernel también tienen sus
>> +propias lista de correo donde hacen sus esfuerzos de desarrollo. Revise el
>> +archivo MAINTAINERS para obtener referencias de lo que estas listas para
>> +los diferentes grupos.
>> +
>> +Muchas de las listas están alojadas en kernel.org. La información sobre
>> +estas puede ser encontrada en:
>> +
>> +	http://vger.kernel.org/vger-lists.html
>> +
>> +Recuerde mantener buenos hábitos de comportamiento al usar las listas.
>> +Aunque un poco cursi, la siguiente URL tiene algunas pautas simples para
>> +interactuar con la lista (o cualquier lista):
>> +
>> +	http://www.albion.com/netiquette/
>> +
>> +Si varias personas responden a su correo, el CC (lista de destinatarios)
>> +puede hacerse bastante grande. No elimine a nadie de la lista CC: sin una
>> +buena razón, o no responda solo a la dirección de la lista. Acostúmbrese
>> +a recibir correos dos veces, una del remitente y otra de la lista, y no
>> +intente ajustar esto agregando encabezados de correo astutos, a la gente no
>> +le gustará.
>> +
>> +Recuerde mantener intacto el contexto y la atribución de sus respuestas,
>> +mantenga las líneas "El hacker John Kernel escribió ...:" en la parte
>> +superior de su respuesta, y agregue sus declaraciones entre las secciones
>> +individuales citadas en lugar de escribiendo en la parte superior del
>> +correo electrónico.
>> +
>> +Si incluye parches en su correo, asegúrese de que sean texto legible sin
>> +formato como se indica en :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
>> +Los desarrolladores del kernel no quieren lidiar con archivos adjuntos o
>> +parches comprimidos; y pueden querer comentar líneas individuales de su
>> +parche, que funciona sólo de esa manera. Asegúrese de emplear un programa
>> +de correo que no altere los espacios ni los tabuladores. Una buena primera
>> +prueba es enviarse el correo a usted mismo, e intentar aplicar su
>> +propio parche. Si eso no funciona, arregle su programa de correo o
>> +reemplace hasta que funcione.
>> +
>> +Sobretodo, recuerde de ser respetuoso con otros subscriptores.
>> +
>> +Colaborando con la comunidad
>> +----------------------------
>> +
>> +El objetivo de la comunidad del kernel es proporcionar el mejor kernel
>> +posible. Cuando envíe un parche para su aceptación, se revisará en sus
>> +méritos técnicos solamente. Entonces, ¿qué deberías ser?
>> +
>> +  - criticas
>> +  - comentarios
>> +  - peticiones de cambios
>> +  - peticiones de justificaciones
>> +  - silencio
>> +
>> +Recuerde, esto es parte de introducir su parche en el kernel. Tiene que ser
>> +capaz de recibir críticas y comentarios sobre sus parches, evaluar
>> +a nivel técnico y re-elaborar sus parches o proporcionar razonamiento claro
>> +y conciso de por qué no se deben hacer tales cambios. Si no hay respuestas
>> +a su publicación, espere unos días e intente de nuevo, a veces las cosas se
>> +pierden dado el gran volumen.
>> +
>> +¿Qué no debería hacer?
>> +
>> +  - esperar ue su parche se acepte sin preguntas
>> +  - actuar de forma defensiva
>> +  - ignorar comentarios
>> +  - enviar el parche de nuevo, sin haber aplicados los cambios pertinentes
>> +
>> +En una comunidad que busca la mejor solución técnica posible, siempre habrá
>> +diferentes opiniones sobre lo beneficioso que es un parche. Tiene que ser
>> +cooperativo y estar dispuesto a adaptar su idea para que encaje dentro
>> +del kernel, o al menos esté dispuesto a demostrar que su idea vale la pena.
>> +Recuerea, estar equivocado es aceptable siempre y cuando estés dispuesto a
>> +trabajar hacia una solución que sea correcta.
>> +
>> +Es normal que las respuestas a su primer parche sean simplemente una lista
>> +de una docena de cosas que debe corregir. Esto **no** implica que su
>> +parche no será aceptado, y **no** es personal. Simplemente corrija todos
>> +los problemas planteados en su parche, y envié otra vez.
>> +
>> +Diferencias entre la comunidad kernel y las estructuras corporativas
>> +--------------------------------------------------------------------
>> +
>> +La comunidad del kernel funciona de manera diferente a la mayoría de los
>> +entornos de desarrollo tradicionales en empresas. Aquí hay una lista de
>> +cosas que puede intentar hacer para evitar problemas:
>> +
>> +  Cosas buenas que decir respecto a los cambios propuestos:
>> +
>> +    - "Esto arregla múltiples problemas."
>> +    - "Esto elimina 2000 lineas de código."
>> +    - "Aquí hay un parche que explica lo que intento describir."
>> +    - "Lo he testeado en 5 arquitecturas distintas..."
>> +    - "Aquí hay una serie de parches menores que..."
>> +    - "Esto mejora el rendimiento en maquinas típicas..."
>> +
>> +  Cosas negativas que debe evitar decir:
>> +
>> +    - "Lo hicimos asi en AIX/ptx/Solaris, de modo que debe ser bueno..."
>> +    - "LLevo haciendo esto 20 años, de modo que..."
>> +    - "Esto lo necesita mi empresa para ganar dinero"
>> +    - "Esto es para la linea de nuestros productos Enterprise"
>> +    - "Aquí esta el documento de 1000 paginas describiendo mi idea"
>> +    - "Llevo 6 meses trabajando en esto..."
>> +    - "Aquí esta un parche de 5000 lineas que..."
>> +    - "He rescrito todo el desastre actual, y aqui esta..."
>> +    - "Tengo un deadline, y este parche debe aplicarse ahora."
>> +
>> +Otra forma en que la comunidad del kernel es diferente a la mayoría de los
>> +entornos de trabajo tradicionales en ingeniería de software, es la
>> +naturaleza sin rostro de interacción. Una de las ventajas de utilizar el
>> +correo electrónico y el IRC como formas principales de comunicación es la
>> +no discriminación por motivos de género o raza. El entorno de trabajo del
>> +kernel de Linux acepta a mujeres y minorías porque todo lo que eres es una
>> +dirección de correo electrónico. El aspecto internacional también ayuda a
>> +nivelar el campo de juego porque no puede adivinar el género basado en
>> +el nombre de una persona. Un hombre puede llamarse Andrea y una mujer puede
>> +llamarse Pat. La mayoría de las mujeres que han trabajado en el kernel de
>> +Linux y han expresado una opinión han tenido experiencias positivas.
>> +
>> +La barrera del idioma puede causar problemas a algunas personas que no se
>> +sientes cómodas con el inglés. Un buen dominio del idioma puede ser
>> +necesario para transmitir ideas correctamente en las listas de correo, por
>> +lo que le recomendamos que revise sus correos electrónicos para asegurarse
>> +de que tengan sentido en inglés antes de enviarlos.
>> +
>> +Divida sus cambios
>> +---------------------
>> +
>> +La comunidad del kernel de Linux no acepta con gusto grandes fragmentos de
>> +código, sobretodo a la vez. Los cambios deben introducirse correctamente,
>> +discutidos y divididos en pequeñas porciones individuales. Esto es casi
>> +exactamente lo contrario de lo que las empresas están acostumbradas a hacer.
>> +Su propuesta también debe introducirse muy temprano en el proceso de
>> +desarrollo, de modo que pueda recibir comentarios sobre lo que está
>> +haciendo. También deje que la comunidad sienta que está trabajando con
>> +ellos, y no simplemente usándolos como un vertedero para su función. Sin
>> +embargo, no envíe 50 correos electrónicos a una vez a una lista de correo,
>> +su serie de parches debe casi siempre ser más pequeña que eso.
>> +
>> +Las razones para dividir las cosas son las siguientes:
>> +
>> +1) Los cambios pequeños aumentan la probabilidad de que sus parches sean
>> +   aplicados, ya que no requieren mucho tiempo o esfuerzo para verificar su
>> +   exactitud. Un parche de 5 líneas puede ser aplicado por un maintainer
>> +   con apenas una segunda mirada. Sin embargo, un parche de 500 líneas
>> +   puede tardar horas en ser revisado en términos de corrección (el tiempo
>> +   que toma es exponencialmente proporcional al tamaño del parche, o algo
>> +   así).
>> +
>> +   Los parches pequeños también facilitan la depuración cuando algo falla.
>> +   Es mucho más fácil retirar los parches uno por uno que diseccionar un
>> +   parche muy grande después de haber sido aplicado (y roto alguna cosa).
>> +
>> +2) Es importante no solo enviar pequeños parches, sino también reescribir
>> +   y simplificar (o simplemente reordenar) los parches antes de enviarlos.
>> +
>> +Esta es una analogía del desarrollador del kernel Al Viro (traducida):
>> +
>> +	*"Piense en un maestro que califica la tarea de un estudiante de
>> +	matemáticas. El maestro no quiere ver los intentos y errores del
>> +	estudiante antes de que se les ocurriera la solución. Quiere ver la
>> +	respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca
>> +	presentaría su trabajo intermedio antes de tener la solución final.*
>> +
>> +	* Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
>> +	revisores no quieren ver el proceso de pensamiento detrás de la solución
>> +	al problema que se está resolviendo. Quieren ver un solución simple y
>> +	elegante."*
>> +
>> +Puede resultar un reto mantener el equilibrio entre presentar una solución
>> +elegante y trabajar junto a la comunidad, discutiendo su trabajo inacabado.
>> +Por lo tanto, es bueno comenzar temprano en el proceso para obtener
>> +"feedback" y mejorar su trabajo, pero también mantenga sus cambios en
>> +pequeños trozos que pueden ser aceptados, incluso cuando toda su labor no
>> +está listo para inclusión en un momento dado.
>> +
>> +También tenga en cuenta que no es aceptable enviar parches para su
>> +inclusión que están sin terminar y serán "arreglados más tarde".
>> +
>> +Justifique sus cambios
>> +----------------------
>> +
>> +Además de dividir sus parches, es muy importante que deje a la comunidad de
>> +Linux sabe por qué deberían agregar este cambio. Nuevas características
>> +debe justificarse como necesarias y útiles.
>> +
>> +Documente sus cambios
>> +--------------------
>> +
>> +Cuando envíe sus parches, preste especial atención a lo que dice en el
>> +texto de su correo electrónico. Esta información se convertirá en el
>> +ChangeLog del parche, y se conservará para que todos la vean, todo el
>> +tiempo. Debe describir el parche por completo y contener:
>> +
>> +  - por que los cambios son necesarios
>> +  - el diseño general de su propuesta
>> +  - detalles de implementación
>> +  - resultados de sus experimentos
>> +
>> +Para obtener más detalles sobre cómo debería quedar todo esto, consulte la
>> +sección ChangeLog del documento:
>> +
>> +  "The Perfect Patch"
>> +      https://www.ozlabs.org/~akpm/stuff/tpp.txt
>> +
>> +Todas estas cuestiones son a veces son muy difíciles de conseguir. Puede
>> +llevar años perfeccionar estas prácticas (si es que lo hace). Es un proceso
>> +continuo de mejora que requiere mucha paciencia y determinación. Pero no se
>> +rinda, es posible. Muchos lo han hecho antes, y cada uno tuvo que comenzar
>> +exactamente donde está usted ahora.
>> +
>> +
>> +----------
>> +
>> +Gracias a Paolo Ciarrocchi que permitió que la sección "Development Process"
>> +se basara en el texto que había escrito (https://lwn.net/Articles/94386/),
>> +y a Randy Dunlap y Gerrit Huizenga por algunas de la lista de cosas que
>> +debes y no debes decir. También gracias a Pat Mochel, Hanna Linder, Randy
>> +Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook,
>> +Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk,
>> +Keri Harris, Frans Pop, David A. Wheeler, Junio ​​Hamano, Michael Kerrisk y
>> +Alex Shepard por su revisión, comentarios y contribuciones. Sin su ayuda,
>> +este documento no hubiera sido posible.
>> +
>> +Maintainer: Greg Kroah-Hartman <greg@kroah.com>
> kernel test robot have already reported documentation warnings at [1],
> so I have applied the fixup:
Nice, I'll make sure to include this in v2
>
> ---- >8 ----
>
> diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
> index 4cf8fa6b9f7c2e..0c072b9a69df30 100644
> --- a/Documentation/translations/sp_SP/howto.rst
> +++ b/Documentation/translations/sp_SP/howto.rst
> @@ -183,7 +183,7 @@ con::
>   	make epubdocs
>   
>   Convertirse en un/a desarrollador/a de kernel
> --------------------------------------------
> +---------------------------------------------
>   
>   Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
>   el proyecto Linux KernelNewbies:
> @@ -274,8 +274,8 @@ Vale la pena mencionar lo que Andrew Morton escribió en las listas de
>   correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
>   
>   	*"Nadie sabe cuándo se publicara un nuevo kernel, porque esto sucede
> -    de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
> -    una línea temporal preconcebida."*
> +        de acuerdo con el estado de bugs (error) percibido, no de acuerdo con
> +        una línea temporal preconcebida."*
>   
>   Varios árboles estables con múltiples major numbers
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> @@ -556,7 +556,7 @@ Esta es una analogía del desarrollador del kernel Al Viro (traducida):
>   	respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca
>   	presentaría su trabajo intermedio antes de tener la solución final.*
>   
> -	* Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
> +	*Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
>   	revisores no quieren ver el proceso de pensamiento detrás de la solución
>   	al problema que se está resolviendo. Quieren ver un solución simple y
>   	elegante."*
> @@ -579,7 +579,7 @@ Linux sabe por qué deberían agregar este cambio. Nuevas características
>   debe justificarse como necesarias y útiles.
>   
>   Documente sus cambios
> ---------------------
> +---------------------
>   
>   Cuando envíe sus parches, preste especial atención a lo que dice en el
>   texto de su correo electrónico. Esta información se convertirá en el
>
> Muchas gracias (thanks very much).
Cheers!
>
> [1]: https://lore.kernel.org/linux-doc/202210141348.7UGXRUp8-lkp@intel.com/

Re: [PATCH 0/2] Documentation: Start Spanish translation and include HOWTO

[Carlos Bilbao]

On 10/13/22 16:09, Jonathan Corbet wrote:

> Carlos Bilbao <carlos.bilbao@amd.com> writes:
>
>> Spanish is the second most spoken language in the world. This patch set
>> starts the process of translating critical kernel documentation into the
>> Spanish language.
>>
>> Carlos Bilbao (2):
>>    Documentation: Start translations to Spanish
>>    Documentation: Add HOWTO Spanish translation into rst based build system
>>
>>   Documentation/translations/index.rst          |   1 +
>>   .../translations/sp_SP/disclaimer-sp.rst      |   6 +
>>   Documentation/translations/sp_SP/howto.rst    | 619 ++++++++++++++++++
>>   Documentation/translations/sp_SP/index.rst    |  80 +++
>>   4 files changed, 706 insertions(+)
>>   create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
>>   create mode 100644 Documentation/translations/sp_SP/howto.rst
>>   create mode 100644 Documentation/translations/sp_SP/index.rst
> I'm happy to see a Spanish translation of the docs, certainly.  I do
> worry, though, that the desire to create translations tends to exceed
> the desire to keep them maintained and current over time. Is it your
> plan to continue to maintain these going forward?  Is anybody else
> planning to help you with this task?
>
> Along those lines, a MAINTAINERS entry for the Spanish translation would
> be a good thing to add.
>
> Thanks,
>
> jon
Absolutely, I’m aware this will require future maintenance, and understand
that is going to mean an effort from my side. I will do it with pleasure. I
just wish I had started earlier.

I’m sending v2 including the pertinent changes in MAINTAINERS. It will also
have minor improvements to make the test robot happy and details found
reviewing the translations again.

I plan to continue translating the rest of files at the pace time permits.

Thanks John,
Carlos

Re: [PATCH 2/2] Documentation: Add HOWTO Spanish translation into rst based build system

[Jonathan Corbet]

Carlos Bilbao <carlos.bilbao@amd.com> writes:

> On 10/14/22 04:21, Bagas Sanjaya wrote:
>
>> ¡Hola Carlos! Gracias for start writing Spanish translations. However,
>> the patch can be improved, see below.
> Hola Bagas, thanks for your feedback :)
>>
>> On Thu, Oct 13, 2022 at 01:48:16PM -0500, Carlos Bilbao wrote:
>>> This commit adds Spanish translation of HOWTO document into rst based
>>> documentation build system.
>>>
>> Better say "Translate HOWTO document into Spanish".
> So, for the commit message here I just replicated what prior folks did,
> see:
>
> For Japanese:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/translations/ja_JP?h=v6.0&id=f012733894d36ff687862e9cd3b02ee980c61416
>
> For Korean:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/translations/ko_KR/howto.rst?h=v6.0&id=ba42c574fc8b803ec206785b7b91325c05810422
>
> I think I will leave that commit message, it is slightly more informative
> than "Translate HOWTO document into Spanish".

Just so you know, the standard advice (as found in submitting-patches.rst) 
is to use the imperative mode in changelogs.  Some maintainers are quite
insistent that things be done that way.  I'm not one of those, though,
so I think the existing message is fine.

Thanks,

jon

[PATCH v2 0/2] Documentation: Start Spanish translation and include HOWTO

[Carlos Bilbao]

Spanish is the second most spoken language in the world. This patch set
starts the process of translating critical kernel documentation into the
Spanish language.

Changes since v1:
  - Added me as MAINTAINER
  - Fixed warnings of kernel test robot
  - Use imperative form in second commit
  - Improved minor translation details

Carlos Bilbao (2):
  Documentation: Start translations to Spanish
  Documentation: Add HOWTO Spanish translation into rst based build system

  Documentation/translations/index.rst          |   1 +
  .../translations/sp_SP/disclaimer-sp.rst      |   6 +
  Documentation/translations/sp_SP/howto.rst    | 617 ++++++++++++++++++
  Documentation/translations/sp_SP/index.rst    |  80 +++
  MAINTAINERS                                   |   5 +
  5 files changed, 709 insertions(+)
  create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
  create mode 100644 Documentation/translations/sp_SP/howto.rst
  create mode 100644 Documentation/translations/sp_SP/index.rst

[PATCH v2 1/2] Documentation: Start translations to Spanish

[Carlos Bilbao]

Start the process of translating kernel documentation to Spanish. Create
sp_SP/ and include an index and a disclaimer, following the approach of
prior translations. Add Carlos Bilbao as MAINTAINER of this translation
effort.

Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
---
 Documentation/translations/index.rst          |  1 +
 .../translations/sp_SP/disclaimer-sp.rst      |  6 ++
 Documentation/translations/sp_SP/index.rst    | 72 +++++++++++++++++++
 MAINTAINERS                                   |  5 ++
 4 files changed, 84 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
 create mode 100644 Documentation/translations/sp_SP/index.rst

diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst
index 1175a47d07f0..b826c34791c0 100644
--- a/Documentation/translations/index.rst
+++ b/Documentation/translations/index.rst
@@ -12,6 +12,7 @@ Translations
    it_IT/index
    ko_KR/index
    ja_JP/index
+   sp_SP/index
 
 
 .. _translations_disclaimer:
diff --git a/Documentation/translations/sp_SP/disclaimer-sp.rst b/Documentation/translations/sp_SP/disclaimer-sp.rst
new file mode 100644
index 000000000000..a400034e95f9
--- /dev/null
+++ b/Documentation/translations/sp_SP/disclaimer-sp.rst
@@ -0,0 +1,6 @@
+:orphan:
+
+.. 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.
diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst
new file mode 100644
index 000000000000..2800041168f4
--- /dev/null
+++ b/Documentation/translations/sp_SP/index.rst
@@ -0,0 +1,72 @@
+.. _sp_linux_doc:
+
+=======================
+Traducción al español
+=======================
+
+.. raw:: latex
+
+	\kerneldocCJKoff
+
+:maintainer: Carlos Bilbao <carlos.bilbao@amd.com>
+
+.. _sp_disclaimer:
+
+Advertencia
+===========
+
+El objetivo de esta traducción es facilitar la lectura y comprensión para
+aquellos que no entiendan inglés o duden de sus interpretaciones, o
+simplemente para aquellos que prefieran leer en el idioma español. Sin
+embargo, tenga en cuenta que la *única* documentación oficial es la que
+está en inglés: :ref:`linux_doc`
+
+La propagación simultanea de la traducción de una modificación en
+:ref:`linux_doc` es altamente improbable. Los maintainers y colaboradores
+de la traducción intentan mantener sus traducciones al día, en tanto les
+es posible. Por tanto, no existe ninguna garantía de que una traducción
+esté actualizada con las ultimas modificaciones. Si lo que lee en una
+traducción no se corresponde con lo que ve en el código fuente, informe
+al maintainer de la traducción y, si puede, consulte la documentación en
+inglés.
+
+Una traducción no es una * bifurcación * de la documentación oficial, por
+lo que los usuarios no encontrarán aquí ninguna información que no sea la
+versión oficial. Cualquier adición, supresión o modificación de los
+contenidos deberá ser realizada anteriormente en los documentos en inglés.
+Posteriormente, y cuando sea posible, dicho cambio debería aplicarse
+también a las traducciones. Los maintainers de las traducciones aceptan
+contribuciones que son puramente de interés relativo a la traducción (por
+ejemplo, nuevas traducciones, actualizaciones, correcciones).
+
+Las traducciones tratan de ser lo más precisas posible pero no es posible
+convertir directamente un idioma a otro. Cada idioma tiene su propia
+gramática, y una cultura tras ella, por lo tanto, la traducción de una
+oración al inglés se podría modificar para adaptarlo al español. Por esta
+razón, cuando lea esta traducción, puede encontrar algunas diferencias en
+la forma, pero todavía transmiten el mensaje original. A pesar de la gran
+difusión del inglés en el idioma hablado, cuando sea posible, expresiones
+en inglés serán reemplazadas por las palabras correspondientes en español.
+
+Si necesita ayuda para comunicarse con la comunidad de Linux pero no se
+siente cómodo escribiendo en inglés, puede pedir ayuda al maintainer para
+obtener una traducción.
+
+Muchos países hablan español, cada uno con su propia cultura, expresiones,
+y diferencias gramaticales en ocasiones significativas. Las traducciones de
+los maintainers pueden utilizar el español con el que dichos maintainers se
+sientan mas cómodos. En principio, estas pequeñas diferencias no deberían
+suponer una gran barrera para hablantes de distintas versiones del español,
+pero en caso de duda se puede consultar a los maintainers.
+
+La documentación del kernel de Linux
+====================================
+
+Este es el nivel superior de la documentación del kernel en idioma español.
+La traducción es incompleta, y podría encontrar advertencias que indiquen
+la falta de una traducción o de un grupo de traducciones.
+
+En términos más generales, la documentación, como el kernel mismo, están en
+constante desarrollo. Las mejoras en la documentación siempre son
+bienvenidas; de modo que, si desea ayudar, únase a la lista de correo de
+linux-doc en vger.kernel.org.
diff --git a/MAINTAINERS b/MAINTAINERS
index 944dc265b64d..b3133f013efb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19150,6 +19150,11 @@ W:	https://linuxtv.org
 Q:	http://patchwork.linuxtv.org/project/linux-media/list/
 F:	drivers/media/dvb-frontends/sp2*
 
+SPANISH DOCUMENTATION
+M:	Carlos Bilbao <carlos.bilbao@amd.com>
+S:	Maintained
+F:	Documentation/translations/sp_SP/
+
 SPARC + UltraSPARC (sparc/sparc64)
 M:	"David S. Miller" <davem@davemloft.net>
 L:	sparclinux@vger.kernel.org
-- 
2.34.1

[PATCH v2 2/2] Documentation: Add HOWTO Spanish translation into rst based build system

[Carlos Bilbao]

Add Spanish translation of HOWTO document into rst based documentation
build system.

Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
---
 Documentation/translations/sp_SP/howto.rst | 617 +++++++++++++++++++++
 Documentation/translations/sp_SP/index.rst |   8 +
 2 files changed, 625 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/howto.rst

diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst
new file mode 100644
index 000000000000..f1375651a1a8
--- /dev/null
+++ b/Documentation/translations/sp_SP/howto.rst
@@ -0,0 +1,617 @@
+.. include:: ./disclaimer-sp.rst
+
+:Original: :ref:`Documentation/process/howto.rst <process_howto>`
+:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
+
+.. _sp_process_howto:
+
+Cómo participar en el desarrollo del kernel de Linux
+====================================================
+
+Este documento es el principal punto de partida. Contiene instrucciones
+sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
+trabajar con el y en su desarrollo. El documento no tratará ningún aspecto
+técnico relacionado con la programación del kernel, pero le ayudará
+guiándole por el camino correcto.
+
+Si algo en este documento quedara obsoleto, envíe parches al maintainer de
+este archivo, que se encuentra en la parte superior del documento.
+
+Introducción
+------------
+¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
+kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
+Linux para este dispositivo." El objetivo de este documento en enseñarle
+todo cuanto necesita para conseguir esto, describiendo el proceso por el
+que debe pasar, y con indicaciones de como trabajar con la comunidad.
+También trata de explicar las razones por las cuales la comunidad trabaja
+de la forma en que lo hace.
+
+El kernel esta principalmente escrito en C, con algunas partes que son
+dependientes de la arquitectura en ensamblador. Un buen conocimiento de C
+es necesario para desarrollar en el kernel. Lenguaje ensamblador (en
+cualquier arquitectura) no es necesario excepto que planee realizar
+desarrollo de bajo nivel para dicha arquitectura. Aunque no es un perfecto
+sustituto para una educación sólida en C y/o años de experiencia, los
+siguientes libros sirven, como mínimo, como referencia:
+
+- "The C Programming Language" de Kernighan e Ritchie [Prentice Hall]
+- "Practical C Programming" de Steve Oualline [O'Reilly]
+- "C:  A Reference Manual" de Harbison and Steele [Prentice Hall]
+
+El kernel está escrito usando GNU C y la cadena de herramientas GNU. Si
+bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que
+no aparecen en dicho estándar. El kernel usa un C independiente de entorno,
+sin depender de la biblioteca C estándar, por lo que algunas partes del
+estándar C no son compatibles. Divisiones de long long arbitrarios o
+de coma flotante no son permitidas. En ocasiones, puede ser difícil de
+entender las suposiciones que el kernel hace respecto a la cadena de
+herramientas y las extensiones que usa, y desafortunadamente no hay
+referencia definitiva para estas. Consulte las páginas de información de
+gcc (`info gcc`) para obtener información al respecto.
+
+Recuerde que está tratando de aprender a trabajar con una comunidad de
+desarrollo existente. Es un grupo diverso de personas, con altos estándares
+de código, estilo y procedimiento. Estas normas han sido creadas a lo
+largo del tiempo en función de lo que se ha encontrado que funciona mejor
+para un equipo tan grande y geográficamente disperso. Trate de aprender
+tanto como le sea posible acerca de estos estándares antes de tiempo, ya
+que están bien documentados; no espere que la gente se adapte a usted o a
+la forma de hacer las cosas en su empresa.
+
+Cuestiones legales
+------------------
+El código fuente del kernel de Linux se publica bajo licencia GPL. Por
+favor, revise el archivo COPYING, presente en la carpeta principal del
+código fuente, para detalles de la licencia. Si tiene alguna otra pregunta
+sobre licencias, contacte a un abogado, no pregunte en listas de discusión
+del kernel de Linux. La gente en estas listas no son abogadas, y no debe
+confiar en sus opiniones en materia legal.
+
+Para preguntas y respuestas más frecuentes sobre la licencia GPL, consulte:
+
+	https://www.gnu.org/licenses/gpl-faq.html
+
+Documentación
+--------------
+El código fuente del kernel de Linux tiene una gran variedad de documentos
+que son increíblemente valiosos para aprender a interactuar con la
+comunidad del kernel. Cuando se agregan nuevas funciones al kernel, se
+recomienda que se incluyan nuevos archivos de documentación que expliquen
+cómo usar la función. Cuando un cambio en el kernel hace que la interfaz
+que el kernel expone espacio de usuario cambie, se recomienda que envíe la
+información o un parche en las páginas del manual que expliquen el cambio
+a mtk.manpages@gmail.com, y CC la lista linux-api@vger.kernel.org.
+
+Esta es la lista de archivos que están en el código fuente del kernel y son
+de obligada lectura:
+
+  :ref:`Documentation/admin-guide/README.rst <readme>`
+    Este archivo ofrece una breve descripción del kernel de Linux y
+    describe lo que es necesario hacer para configurar y compilar el
+    kernel. Quienes sean nuevos en el kernel deben comenzar aquí.
+
+  :ref:`Documentation/process/changes.rst <changes>`
+    Este archivo proporciona una lista de los niveles mínimos de varios
+    paquetes que son necesarios para construir y ejecutar el kernel
+    exitosamente.
+
+  :ref:`Documentation/process/coding-style.rst <codingstyle>`
+    Esto describe el estilo de código del kernel de Linux y algunas de los
+    razones detrás de esto. Se espera que todo el código nuevo siga las
+    directrices de este documento. La mayoría de los maintainers solo
+    aceptarán parches si se siguen estas reglas, y muchas personas solo
+    revisan el código si tiene el estilo adecuado.
+
+  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+    Este archivo describe en gran detalle cómo crear con éxito y enviar un
+    parche, que incluye (pero no se limita a):
+
+       - Contenidos del correo electrónico (email)
+       - Formato del email
+       - A quien se debe enviar
+
+    Seguir estas reglas no garantiza el éxito (ya que todos los parches son
+    sujetos a escrutinio de contenido y estilo), pero en caso de no seguir
+    dichas reglas, el fracaso es prácticamente garantizado.
+    Otras excelentes descripciones de cómo crear parches correctamente son:
+
+	"The Perfect Patch"
+		https://www.ozlabs.org/~akpm/stuff/tpp.txt
+
+	"Linux kernel patch submission format"
+		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html
+
+  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
+    Este archivo describe la lógica detrás de la decisión consciente de
+    no tener una API estable dentro del kernel, incluidas cosas como:
+
+      - Capas intermedias del subsistema (por compatibilidad?)
+      - Portabilidad de drivers entre sistemas operativos
+      - Mitigar el cambio rápido dentro del árbol de fuentes del kernel (o
+        prevenir cambios rápidos)
+
+     Este documento es crucial para comprender la filosofía del desarrollo
+     de Linux y es muy importante para las personas que se mudan a Linux
+     tras desarrollar otros sistemas operativos.
+
+  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
+    Si cree que ha encontrado un problema de seguridad en el kernel de
+    Linux, siga los pasos de este documento para ayudar a notificar a los
+    desarrolladores del kernel y ayudar a resolver el problema.
+
+  :ref:`Documentation/process/management-style.rst <managementstyle>`
+    Este documento describe cómo operan los maintainers del kernel de Linux
+    y los valores compartidos detrás de sus metodologías. Esta es una
+    lectura importante para cualquier persona nueva en el desarrollo del
+    kernel (o cualquier persona que simplemente sienta curiosidad por
+    el campo IT), ya que clarifica muchos conceptos erróneos y confusiones
+    comunes sobre el comportamiento único de los maintainers del kernel.
+
+  :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
+    Este archivo describe las reglas sobre cómo se suceden las versiones
+    del kernel estable, y qué hacer si desea obtener un cambio en una de
+    estas publicaciones.
+
+  :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
+    Una lista de documentación externa relativa al desarrollo del kernel.
+    Por favor consulte esta lista si no encuentra lo que están buscando
+    dentro de la documentación del kernel.
+
+  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
+    Una buena introducción que describe exactamente qué es un parche y cómo
+    aplicarlo a las diferentes ramas de desarrollo del kernel.
+
+El kernel también tiene una gran cantidad de documentos que pueden ser
+generados automáticamente desde el propio código fuente o desde
+ReStructuredText markups (ReST), como este. Esto incluye un descripción
+completa de la API en el kernel y reglas sobre cómo manejar cerrojos
+(locking) correctamente.
+
+Todos estos documentos se pueden generar como PDF o HTML ejecutando::
+
+	make pdfdocs
+	make htmldocs
+
+respectivamente desde el directorio fuente principal del kernel.
+
+Los documentos que utilizan el markup ReST se generarán en
+Documentation/output. También se pueden generar en formatos LaTeX y ePub
+con::
+
+	make latexdocs
+	make epubdocs
+
+Convertirse en un/a desarrollador/a de kernel
+---------------------------------------------
+
+Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
+el proyecto Linux KernelNewbies:
+
+	https://kernelnewbies.org
+
+Consiste en una útil lista de correo donde puede preguntar casi cualquier
+tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en
+los archivos primero, antes de preguntar algo que ya ha sido respondido en
+el pasado.) También tiene un canal IRC que puede usar para hacer preguntas
+en tiempo real, y una gran cantidad de documentación útil para ir
+aprendiendo sobre el desarrollo del kernel de Linux.
+
+El sitio web tiene información básica sobre la organización del código,
+subsistemas, y proyectos actuales (tanto dentro como fuera del árbol).
+También describe alguna información logística básica, como cómo compilar
+un kernel y aplicar un parche.
+
+Si no sabe por dónde quiere empezar, pero quieres buscar alguna tarea que
+comenzar a hacer para unirse a la comunidad de desarrollo del kernel,
+acuda al proyecto Linux Kernel Janitor:
+
+	https://kernelnewbies.org/KernelJanitors
+
+Es un gran lugar para comenzar. Describe una lista de problemas
+relativamente simples que deben limpiarse y corregirse dentro del código
+fuente del kernel de Linux árbol de fuentes. Trabajando con los
+desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos
+para incluir su parche en el árbol del kernel de Linux, y posiblemente
+descubrir en la dirección en que trabajar a continuación, si no tiene ya
+una idea.
+
+Antes de realizar cualquier modificación real al código del kernel de
+Linux, es imperativo entender cómo funciona el código en cuestión. Para
+este propósito, nada es mejor que leerlo directamente (lo más complicado
+está bien comentado), tal vez incluso con la ayuda de herramientas
+especializadas. Una de esas herramientas que se recomienda especialmente
+es el proyecto Linux Cross-Reference, que es capaz de presentar el código
+fuente en un formato de página web indexada y autorreferencial. Una
+excelente puesta al día del repositorio del código del kernel se puede
+encontrar en:
+
+	https://elixir.bootlin.com/
+
+El proceso de desarrollo
+------------------------
+
+El proceso de desarrollo del kernel de Linux consiste actualmente de
+diferentes "branches" (ramas) con muchos distintos subsistemas específicos
+a cada una de ellas. Las diferentes ramas son:
+
+  - El código principal de Linus (mainline tree)
+  - Varios árboles estables con múltiples major numbers
+  - Subsistemas específicos
+  - linux-next, para integración y testing
+
+Mainline tree (Árbol principal)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en
+https://kernel.org o en su repo.  El proceso de desarrollo es el siguiente:
+
+  - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos
+    semanas, durante este período de tiempo, los maintainers pueden enviar
+    grandes modificaciones a Linus, por lo general los parches que ya se
+    han incluido en el linux-next durante unas semanas. La forma preferida
+    de enviar grandes cambios es usando git (la herramienta de
+    administración de código fuente del kernel, más información al respecto
+    en https://git-scm.com/), pero los parches simples también son validos.
+  - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra
+    en hacer el kernel nuevo lo más estable ("solido") posible. La mayoría
+    de los parches en este punto deben arreglar una regresión. Los errores
+    que siempre han existido no son regresiones, por lo tanto, solo envíe
+    este tipo de correcciones si son importantes. Tenga en cuenta que se
+    podría aceptar un controlador (o sistema de archivos) completamente
+    nuevo después de -rc1 porque no hay riesgo de causar regresiones con
+    tal cambio, siempre y cuando el cambio sea autónomo y no afecte áreas
+    fuera del código que se está agregando. git se puede usar para enviar
+    parches a Linus después de que se lance -rc1, pero los parches también
+    deben ser enviado a una lista de correo pública para su revisión.
+  - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git
+    actual esta en un estado razonablemente sano y adecuado para la prueba.
+    La meta es lanzar un nuevo kernel -rc cada semana.
+  - El proceso continúa hasta que el kernel se considera "listo", y esto
+    puede durar alrededor de 6 semanas.
+
+Vale la pena mencionar lo que Andrew Morton escribió en las listas de
+correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
+
+	*"Nadie sabe cuándo se publicara un nuevo kernel, pues esto sucede
+	según el estado de los bugs, no de una cronología preconcebida."*
+
+Varios árboles estables con múltiples major numbers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Los kernels con versiones de 3 partes son kernels estables. Estos contienen
+correcciones relativamente pequeñas y críticas para problemas de seguridad
+o importantes regresiones descubiertas para una publicación de código.
+Cada lanzamiento en una gran serie estable incrementa la tercera parte de
+la versión número, manteniendo las dos primeras partes iguales.
+
+Esta es la rama recomendada para los usuarios que quieren la versión
+estable más reciente del kernel, y no están interesados ​​en ayudar a probar
+versiones en desarrollo/experimentales.
+
+Los árboles estables son mantenidos por el equipo "estable"
+<stable@vger.kernel.org>, y se liberan (publican) según lo dicten las
+necesidades. El período de liberación normal es de aproximadamente dos
+semanas, pero puede ser más largo si no hay problemas apremiantes. Un
+problema relacionado con la seguridad, en cambio, puede causar un
+lanzamiento casi instantáneamente.
+
+El archivo :ref:`Documentación/proceso/stable-kernel-rules.rst <stable_kernel_rules>`
+en el árbol del kernel documenta qué tipos de cambios son aceptables para
+el árbol estable y cómo funciona el proceso de lanzamiento.
+
+Subsistemas específicos
+~~~~~~~~~~~~~~~~~~~~~~~~
+Los maintainers de los diversos subsistemas del kernel --- y también muchos
+desarrolladores de subsistemas del kernel --- exponen su estado actual de
+desarrollo en repositorios fuente. De esta manera, otros pueden ver lo que
+está sucediendo en las diferentes áreas del kernel. En áreas donde el
+desarrollo es rápido, se le puede pedir a un desarrollador que base sus
+envíos en tal árbol del subsistema del kernel, para evitar conflictos entre
+este y otros trabajos ya en curso.
+
+La mayoría de estos repositorios son árboles git, pero también hay otros
+SCM en uso, o colas de parches que se publican como series quilt. Las
+direcciones de estos repositorios de subsistemas se enumeran en el archivo
+MAINTAINERS. Muchos de estos se pueden ver en https://git.kernel.org/.
+
+Antes de que un parche propuesto se incluya con dicho árbol de subsistemas,
+es sujeto a revisión, que ocurre principalmente en las listas de correo
+(ver la sección respectiva a continuación). Para varios subsistemas del
+kernel, esta revisión se rastrea con la herramienta patchwork. Patchwork
+ofrece una interfaz web que muestra publicaciones de parches, cualquier
+comentario sobre un parche o revisiones a él, y los maintainers pueden
+marcar los parches como en revisión, aceptado, o rechazado. La mayoría de
+estos sitios de trabajo de parches se enumeran en
+
+https://patchwork.kernel.org/.
+
+linux-next, para integración y testing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Antes de que las actualizaciones de los árboles de subsistemas se combinen
+con el árbol principal, necesitan probar su integración. Para ello, existe
+un repositorio especial de pruebas en el que se encuentran casi todos los
+árboles de subsistema, actualizado casi a diario:
+
+	https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
+
+De esta manera, linux-next ofrece una perspectiva resumida de lo que se
+espera que entre en el kernel principal en el próximo período de "merge"
+(fusión de código). Los testers aventureros son bienvenidos a probar
+linux-next en ejecución.
+
+Reportar bugs
+-------------
+
+El archivo 'Documentación/admin-guide/reporting-issues.rst' en el
+directorio principal del kernel describe cómo informar un posible bug del
+kernel y detalles sobre qué tipo de información necesitan los
+desarrolladores del kernel para ayudar a rastrear la fuente del problema.
+
+Gestión de informes de bugs
+------------------------------
+
+Una de las mejores formas de poner en práctica sus habilidades de hacking
+es arreglando errores reportados por otras personas. No solo ayudará a
+hacer el kernel más estable, también aprenderá a solucionar problemas del
+mundo real y mejora sus habilidades, y otros desarrolladores se darán
+cuenta de tu presencia. La corrección de errores es una de las mejores
+formas de ganar méritos entre desarrolladores, porque no a muchas personas
+les gusta perder el tiempo arreglando los errores de otras personas.
+
+Para trabajar en informes de errores ya reportados, busque un subsistema
+que le interese. Verifique el archivo MAINTAINERS donde se informan los
+errores de ese subsistema; con frecuencia será una lista de correo, rara
+vez un rastreador de errores (bugtracker). Busque en los archivos de dicho
+lugar para informes recientes y ayude donde lo crea conveniente. También es
+posible que desee revisar https://bugzilla.kernel.org para informes de
+errores; solo un puñado de subsistemas del kernel lo emplean activamente
+para informar o rastrear; sin embargo, todos los errores para todo el kernel
+se archivan allí.
+
+Listas de correo
+-----------------
+
+Como se explica en algunos de los documentos anteriores, la mayoría de
+desarrolladores del kernel participan en la lista de correo del kernel de
+Linux. Detalles sobre cómo para suscribirse y darse de baja de la lista se
+pueden encontrar en:
+
+	http://vger.kernel.org/vger-lists.html#linux-kernel
+
+Existen archivos de la lista de correo en la web en muchos lugares
+distintos. Utilice un motor de búsqueda para encontrar estos archivos. Por
+ejemplo:
+
+	http://dir.gmane.org/gmane.linux.kernel
+
+Es muy recomendable que busque en los archivos sobre el tema que desea
+tratar, antes de publicarlo en la lista. Un montón de cosas ya discutidas
+en detalle solo se registran en los archivos de la lista de correo.
+
+La mayoría de los subsistemas individuales del kernel también tienen sus
+propias lista de correo donde hacen sus esfuerzos de desarrollo. Revise el
+archivo MAINTAINERS para obtener referencias de lo que estas listas para
+los diferentes grupos.
+
+Muchas de las listas están alojadas en kernel.org. La información sobre
+estas puede ser encontrada en:
+
+	http://vger.kernel.org/vger-lists.html
+
+Recuerde mantener buenos hábitos de comportamiento al usar las listas.
+Aunque un poco cursi, la siguiente URL tiene algunas pautas simples para
+interactuar con la lista (o cualquier lista):
+
+	http://www.albion.com/netiquette/
+
+Si varias personas responden a su correo, el CC (lista de destinatarios)
+puede hacerse bastante grande. No elimine a nadie de la lista CC: sin una
+buena razón, o no responda solo a la dirección de la lista. Acostúmbrese
+a recibir correos dos veces, una del remitente y otra de la lista, y no
+intente ajustar esto agregando encabezados de correo astutos, a la gente no
+le gustará.
+
+Recuerde mantener intacto el contexto y la atribución de sus respuestas,
+mantenga las líneas "El hacker John Kernel escribió ...:" en la parte
+superior de su respuesta, y agregue sus declaraciones entre las secciones
+individuales citadas en lugar de escribiendo en la parte superior del
+correo electrónico.
+
+Si incluye parches en su correo, asegúrese de que sean texto legible sin
+formato como se indica en :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
+Los desarrolladores del kernel no quieren lidiar con archivos adjuntos o
+parches comprimidos; y pueden querer comentar líneas individuales de su
+parche, que funciona sólo de esa manera. Asegúrese de emplear un programa
+de correo que no altere los espacios ni los tabuladores. Una buena primera
+prueba es enviarse el correo a usted mismo, e intentar aplicar su
+propio parche. Si eso no funciona, arregle su programa de correo o
+reemplace hasta que funcione.
+
+Sobretodo, recuerde de ser respetuoso con otros subscriptores.
+
+Colaborando con la comunidad
+----------------------------
+
+El objetivo de la comunidad del kernel es proporcionar el mejor kernel
+posible. Cuando envíe un parche para su aceptación, se revisará en sus
+méritos técnicos solamente. Entonces, ¿qué deberías ser?
+
+  - críticas
+  - comentarios
+  - peticiones de cambios
+  - peticiones de justificaciones
+  - silencio
+
+Recuerde, esto es parte de introducir su parche en el kernel. Tiene que ser
+capaz de recibir críticas y comentarios sobre sus parches, evaluar
+a nivel técnico y re-elaborar sus parches o proporcionar razonamiento claro
+y conciso de por qué no se deben hacer tales cambios. Si no hay respuestas
+a su publicación, espere unos días e intente de nuevo, a veces las cosas se
+pierden dado el gran volumen.
+
+¿Qué no debería hacer?
+
+  - esperar que su parche se acepte sin preguntas
+  - actuar de forma defensiva
+  - ignorar comentarios
+  - enviar el parche de nuevo, sin haber aplicados los cambios pertinentes
+
+En una comunidad que busca la mejor solución técnica posible, siempre habrá
+diferentes opiniones sobre lo beneficioso que es un parche. Tiene que ser
+cooperativo y estar dispuesto a adaptar su idea para que encaje dentro
+del kernel, o al menos esté dispuesto a demostrar que su idea vale la pena.
+Recuerde, estar equivocado es aceptable siempre y cuando estés dispuesto a
+trabajar hacia una solución que sea correcta.
+
+Es normal que las respuestas a su primer parche sean simplemente una lista
+de una docena de cosas que debe corregir. Esto **no** implica que su
+parche no será aceptado, y **no** es personal. Simplemente corrija todos
+los problemas planteados en su parche, y envié otra vez.
+
+Diferencias entre la comunidad kernel y las estructuras corporativas
+--------------------------------------------------------------------
+
+La comunidad del kernel funciona de manera diferente a la mayoría de los
+entornos de desarrollo tradicionales en empresas. Aquí hay una lista de
+cosas que puede intentar hacer para evitar problemas:
+
+  Cosas buenas que decir respecto a los cambios propuestos:
+
+    - "Esto arregla múltiples problemas."
+    - "Esto elimina 2000 lineas de código."
+    - "Aquí hay un parche que explica lo que intento describir."
+    - "Lo he testeado en 5 arquitecturas distintas..."
+    - "Aquí hay una serie de parches menores que..."
+    - "Esto mejora el rendimiento en maquinas típicas..."
+
+  Cosas negativas que debe evitar decir:
+
+    - "Lo hicimos así en AIX/ptx/Solaris, de modo que debe ser bueno..."
+    - "Llevo haciendo esto 20 años, de modo que..."
+    - "Esto lo necesita mi empresa para ganar dinero"
+    - "Esto es para la linea de nuestros productos Enterprise"
+    - "Aquí esta el documento de 1000 paginas describiendo mi idea"
+    - "Llevo 6 meses trabajando en esto..."
+    - "Aquí esta un parche de 5000 lineas que..."
+    - "He rescrito todo el desastre actual, y aquí esta..."
+    - "Tengo un deadline, y este parche debe aplicarse ahora."
+
+Otra forma en que la comunidad del kernel es diferente a la mayoría de los
+entornos de trabajo tradicionales en ingeniería de software, es la
+naturaleza sin rostro de interacción. Una de las ventajas de utilizar el
+correo electrónico y el IRC como formas principales de comunicación es la
+no discriminación por motivos de género o raza. El entorno de trabajo del
+kernel de Linux acepta a mujeres y minorías porque todo lo que eres es una
+dirección de correo electrónico. El aspecto internacional también ayuda a
+nivelar el campo de juego porque no puede adivinar el género basado en
+el nombre de una persona. Un hombre puede llamarse Andrea y una mujer puede
+llamarse Pat. La mayoría de las mujeres que han trabajado en el kernel de
+Linux y han expresado una opinión han tenido experiencias positivas.
+
+La barrera del idioma puede causar problemas a algunas personas que no se
+sientes cómodas con el inglés. Un buen dominio del idioma puede ser
+necesario para transmitir ideas correctamente en las listas de correo, por
+lo que le recomendamos que revise sus correos electrónicos para asegurarse
+de que tengan sentido en inglés antes de enviarlos.
+
+Divida sus cambios
+---------------------
+
+La comunidad del kernel de Linux no acepta con gusto grandes fragmentos de
+código, sobretodo a la vez. Los cambios deben introducirse correctamente,
+discutidos y divididos en pequeñas porciones individuales. Esto es casi
+exactamente lo contrario de lo que las empresas están acostumbradas a hacer.
+Su propuesta también debe introducirse muy temprano en el proceso de
+desarrollo, de modo que pueda recibir comentarios sobre lo que está
+haciendo. También deje que la comunidad sienta que está trabajando con
+ellos, y no simplemente usándolos como un vertedero para su función. Sin
+embargo, no envíe 50 correos electrónicos a una vez a una lista de correo,
+su serie de parches debe casi siempre ser más pequeña que eso.
+
+Las razones para dividir las cosas son las siguientes:
+
+1) Los cambios pequeños aumentan la probabilidad de que sus parches sean
+   aplicados, ya que no requieren mucho tiempo o esfuerzo para verificar su
+   exactitud. Un parche de 5 líneas puede ser aplicado por un maintainer
+   con apenas una segunda mirada. Sin embargo, un parche de 500 líneas
+   puede tardar horas en ser revisado en términos de corrección (el tiempo
+   que toma es exponencialmente proporcional al tamaño del parche, o algo
+   así).
+
+   Los parches pequeños también facilitan la depuración cuando algo falla.
+   Es mucho más fácil retirar los parches uno por uno que diseccionar un
+   parche muy grande después de haber sido aplicado (y roto alguna cosa).
+
+2) Es importante no solo enviar pequeños parches, sino también reescribir
+   y simplificar (o simplemente reordenar) los parches antes de enviarlos.
+
+Esta es una analogía del desarrollador del kernel Al Viro (traducida):
+
+	*"Piense en un maestro que califica la tarea de un estudiante de
+	matemáticas. El maestro no quiere ver los intentos y errores del
+	estudiante antes de que se les ocurriera la solución. Quiere ver la
+	respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca
+	presentaría su trabajo intermedio antes de tener la solución final.*
+
+	*Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
+	revisores no quieren ver el proceso de pensamiento detrás de la solución
+	al problema que se está resolviendo. Quieren ver un solución simple y
+	elegante."*
+
+Puede resultar un reto mantener el equilibrio entre presentar una solución
+elegante y trabajar junto a la comunidad, discutiendo su trabajo inacabado.
+Por lo tanto, es bueno comenzar temprano en el proceso para obtener
+"feedback" y mejorar su trabajo, pero también mantenga sus cambios en
+pequeños trozos que pueden ser aceptados, incluso cuando toda su labor no
+está listo para inclusión en un momento dado.
+
+También tenga en cuenta que no es aceptable enviar parches para su
+inclusión que están sin terminar y serán "arreglados más tarde".
+
+Justifique sus cambios
+----------------------
+
+Además de dividir sus parches, es muy importante que deje a la comunidad de
+Linux sabe por qué deberían agregar este cambio. Nuevas características
+debe justificarse como necesarias y útiles.
+
+Documente sus cambios
+---------------------
+
+Cuando envíe sus parches, preste especial atención a lo que dice en el
+texto de su correo electrónico. Esta información se convertirá en el
+ChangeLog del parche, y se conservará para que todos la vean, todo el
+tiempo. Debe describir el parche por completo y contener:
+
+  - por qué los cambios son necesarios
+  - el diseño general de su propuesta
+  - detalles de implementación
+  - resultados de sus experimentos
+
+Para obtener más detalles sobre cómo debería quedar todo esto, consulte la
+sección ChangeLog del documento:
+
+  "The Perfect Patch"
+      https://www.ozlabs.org/~akpm/stuff/tpp.txt
+
+Todas estas cuestiones son a veces son muy difíciles de conseguir. Puede
+llevar años perfeccionar estas prácticas (si es que lo hace). Es un proceso
+continuo de mejora que requiere mucha paciencia y determinación. Pero no se
+rinda, es posible. Muchos lo han hecho antes, y cada uno tuvo que comenzar
+exactamente donde está usted ahora.
+
+----------
+
+Gracias a Paolo Ciarrocchi que permitió que la sección "Development Process"
+se basara en el texto que había escrito (https://lwn.net/Articles/94386/),
+y a Randy Dunlap y Gerrit Huizenga por algunas de la lista de cosas que
+debes y no debes decir. También gracias a Pat Mochel, Hanna Linder, Randy
+Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook,
+Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk,
+Keri Harris, Frans Pop, David A. Wheeler, Junio ​​Hamano, Michael Kerrisk y
+Alex Shepard por su revisión, comentarios y contribuciones. Sin su ayuda,
+este documento no hubiera sido posible.
+
+Maintainer: Greg Kroah-Hartman <greg@kroah.com>
diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst
index 2800041168f4..1d5d1154d309 100644
--- a/Documentation/translations/sp_SP/index.rst
+++ b/Documentation/translations/sp_SP/index.rst
@@ -70,3 +70,11 @@ En términos más generales, la documentación, como el kernel mismo, están en
 constante desarrollo. Las mejoras en la documentación siempre son
 bienvenidas; de modo que, si desea ayudar, únase a la lista de correo de
 linux-doc en vger.kernel.org.
+
+Traducciones al español
+=======================
+
+.. toctree::
+   :maxdepth: 1
+
+   howto
-- 
2.34.1

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Miguel Ojeda]

Hi Carlos,

Since you Cc'd me, I guess I can give a quick review. :)

On Fri, Oct 14, 2022 at 4:40 PM Carlos Bilbao <carlos.bilbao@amd.com> wrote:
>
> +=======================
> +Traducción al español
> +=======================

I think these should be as long as the title.

> +La propagación simultanea de la traducción de una modificación en

"simultánea"

> +esté actualizada con las ultimas modificaciones. Si lo que lee en una

"últimas"

> +Una traducción no es una * bifurcación * de la documentación oficial, por

I am not sure if the spaces are needed.

> +ejemplo, nuevas traducciones, actualizaciones, correcciones).

"...", "etc." or "o"/"y" before  "correcciones"?

> +Las traducciones tratan de ser lo más precisas posible pero no es posible
> +convertir directamente un idioma a otro. Cada idioma tiene su propia
> +gramática, y una cultura tras ella, por lo tanto, la traducción de una
> +oración al inglés se podría modificar para adaptarlo al español. Por esta

"adaptarla"? (if you are referring to "la traducción" or "una oración")

> +la forma, pero todavía transmiten el mensaje original. A pesar de la gran
> +difusión del inglés en el idioma hablado, cuando sea posible, expresiones
> +en inglés serán reemplazadas por las palabras correspondientes en español.

I think the sentence wants to say it is common (in the community?) to
use English, but terms will be translated where possible. However, I
am not sure what "en el idioma hablado" means here.

Also, was this based on the English version or another translation?
i.e. this sentence does not seem to be in the English one.

> +sientan mas cómodos. En principio, estas pequeñas diferencias no deberían

"más"

> +La documentación del kernel de Linux
> +====================================

I think without the last "de" would be more precise, but I have heard
it this way too.

> +bienvenidas; de modo que, si desea ayudar, únase a la lista de correo de
> +linux-doc en vger.kernel.org.

Ditto.

Cheers,
Miguel

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Carlos Bilbao]

On 10/14/22 10:21, Miguel Ojeda wrote:

> Hi Carlos,
>
> Since you Cc'd me, I guess I can give a quick review. :)
Thanks Miguel. You came to mind immediately when thinking about CCing
someone else that's a native speaker.
>
> On Fri, Oct 14, 2022 at 4:40 PM Carlos Bilbao <carlos.bilbao@amd.com> wrote:
>> +=======================
>> +Traducción al español
>> +=======================
> I think these should be as long as the title.
>
>> +La propagación simultanea de la traducción de una modificación en
> "simultánea"
>
>> +esté actualizada con las ultimas modificaciones. Si lo que lee en una
> "últimas"
>
>> +Una traducción no es una * bifurcación * de la documentación oficial, por
> I am not sure if the spaces are needed.
>
>> +ejemplo, nuevas traducciones, actualizaciones, correcciones).
> "...", "etc." or "o"/"y" before  "correcciones"?
>
>> +Las traducciones tratan de ser lo más precisas posible pero no es posible
>> +convertir directamente un idioma a otro. Cada idioma tiene su propia
>> +gramática, y una cultura tras ella, por lo tanto, la traducción de una
>> +oración al inglés se podría modificar para adaptarlo al español. Por esta
> "adaptarla"? (if you are referring to "la traducción" or "una oración")
>
>> +la forma, pero todavía transmiten el mensaje original. A pesar de la gran
>> +difusión del inglés en el idioma hablado, cuando sea posible, expresiones
>> +en inglés serán reemplazadas por las palabras correspondientes en español.
> I think the sentence wants to say it is common (in the community?) to
> use English, but terms will be translated where possible. However, I
> am not sure what "en el idioma hablado" means here.
>
> Also, was this based on the English version or another translation?
> i.e. this sentence does not seem to be in the English one.
Yep, I took this from the Italian translation. They added:

"Nonostante la grande diffusione di inglesismi nella lingua parlata, quando
possibile, questi verranno sostituiti dalle corrispettive parole italiane"

which in English is (more less):

"Despite the popularity of English language in our field, use the
corresponding term in Italian when possible."

I believe the idea is that, even though we inherited English terms, like
"bug", we should try to translate as much as possible and don't fall into
what people sometimes refer to "Spanenglish", mixing both languages.
>
>> +sientan mas cómodos. En principio, estas pequeñas diferencias no deberían
> "más"
>
>> +La documentación del kernel de Linux
>> +====================================
> I think without the last "de" would be more precise, but I have heard
> it this way too.
>
>> +bienvenidas; de modo que, si desea ayudar, únase a la lista de correo de
>> +linux-doc en vger.kernel.org.
> Ditto.
Thanks for your feedback, Miguel. I will wait to see if John has anything
to add before I share updated patches.
>
> Cheers,
> Miguel

Best regards,

Carlos

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Jonathan Corbet]

Carlos Bilbao <carlos.bilbao@amd.com> writes:

> Thanks for your feedback, Miguel. I will wait to see if John has anything
> to add before I share updated patches.

I am, alas, not well qualified to judge a Spanish translation (leggo
facilmente quello italiano, invece :), so I don't have anything to add
there.

There's no hurry in any case, I'll not apply this before the merge
window closes.

Thanks,

jon

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Carlos Bilbao]

On 10/14/22 10:36, Jonathan Corbet wrote:

> Carlos Bilbao <carlos.bilbao@amd.com> writes:
>
>> Thanks for your feedback, Miguel. I will wait to see if John has anything
>> to add before I share updated patches.
> I am, alas, not well qualified to judge a Spanish translation (leggo
> facilmente quello italiano, invece :), so I don't have anything to add
> there.
>
> There's no hurry in any case, I'll not apply this before the merge
> window closes.
Sounds good! In that case, I will wait a week to resend, to also give time
for more potential feedback.
>
> Thanks,
>
> jon

Thanks,

Carlos

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Miguel Ojeda]

On Fri, Oct 14, 2022 at 5:33 PM Carlos Bilbao <carlos.bilbao@amd.com> wrote:
>
> Thanks Miguel. You came to mind immediately when thinking about CCing
> someone else that's a native speaker.

My pleasure!

> I believe the idea is that, even though we inherited English terms, like
> "bug", we should try to translate as much as possible and don't fall into
> what people sometimes refer to "Spanenglish", mixing both languages.

Yeah, that was what I was thinking. Personally, I think translating
common words like "bug" is fine, but more technical ones like
"spinlock" may make things harder later when the reader goes into the
source code or English docs.

Thanks!

I forgot, by the way: with the typos I mentioned fixed, it looks fine to me:

    Reviewed-by: Miguel Ojeda <ojeda@kernel.org>

Cheers,
Miguel

Re: [PATCH v2 2/2] Documentation: Add HOWTO Spanish translation into rst based build system

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

On Fri, Oct 14, 2022 at 09:24:54AM -0500, Carlos Bilbao wrote:
> Add Spanish translation of HOWTO document into rst based documentation
> build system.
> 

LGTM (all warnings in v1 are fixed), gracias. I left the review on
wordings to actual native speakers.

Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 0/2] Documentation: Start Spanish translation and include HOWTO

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

On Fri, Oct 14, 2022 at 09:24:52AM -0500, Carlos Bilbao wrote:
>   Documentation/translations/index.rst          |   1 +
>   .../translations/sp_SP/disclaimer-sp.rst      |   6 +
>   Documentation/translations/sp_SP/howto.rst    | 617 ++++++++++++++++++
>   Documentation/translations/sp_SP/index.rst    |  80 +++
>   MAINTAINERS                                   |   5 +
>   5 files changed, 709 insertions(+)
>   create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
>   create mode 100644 Documentation/translations/sp_SP/howto.rst
>   create mode 100644 Documentation/translations/sp_SP/index.rst

Why not es_ES locale slug instead?

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Akira Yokosawa]

Hi,
Minor nit on language code.

On Fri, 14 Oct 2022 09:24:53 -0500, Carlos Bilbao wrote:
> Start the process of translating kernel documentation to Spanish. Create
> sp_SP/ and include an index and a disclaimer, following the approach of
> prior translations. Add Carlos Bilbao as MAINTAINER of this translation
> effort.
IIUC, the language code for "Spanish (Spain)" should be "es-ES", as is
listed at e.g., http://www.lingoes.net/en/translator/langcode.htm.

The other translations use directory names found in the table, with
"-" replaced with "_".  It would be better to be consistent.

Just my two cents.

        Thanks, Akira

> 
> Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.com>
> ---
>  Documentation/translations/index.rst          |  1 +
>  .../translations/sp_SP/disclaimer-sp.rst      |  6 ++
>  Documentation/translations/sp_SP/index.rst    | 72 +++++++++++++++++++
>  MAINTAINERS                                   |  5 ++
>  4 files changed, 84 insertions(+)
>  create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
>  create mode 100644 Documentation/translations/sp_SP/index.rst
> 
> diff --git a/Documentation/translations/index.rst b/Documentation/translations/index.rst
> index 1175a47d07f0..b826c34791c0 100644
> --- a/Documentation/translations/index.rst
> +++ b/Documentation/translations/index.rst
> @@ -12,6 +12,7 @@ Translations
>     it_IT/index
>     ko_KR/index
>     ja_JP/index
> +   sp_SP/index
>  
>  

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Matthew Wilcox]

On Sat, Oct 15, 2022 at 01:06:36PM +0900, Akira Yokosawa wrote:
> Hi,
> Minor nit on language code.
> 
> On Fri, 14 Oct 2022 09:24:53 -0500, Carlos Bilbao wrote:
> > Start the process of translating kernel documentation to Spanish. Create
> > sp_SP/ and include an index and a disclaimer, following the approach of
> > prior translations. Add Carlos Bilbao as MAINTAINER of this translation
> > effort.
> IIUC, the language code for "Spanish (Spain)" should be "es-ES", as is
> listed at e.g., http://www.lingoes.net/en/translator/langcode.htm.
> 
> The other translations use directory names found in the table, with
> "-" replaced with "_".  It would be better to be consistent.

I don't know what standard we're actually following.  RFC5646 suggests
simply using "es", with "es-419" for Latin America specialisation or
"es-ES" for Spain.  I don't know how much variation there is between
different Spanish dialects for technical documents; as I understand it,
it's worth supporting two dialects of Chinese, but we merrily mix &
match en_US and en_GB spellings.  Similarly, I wouldn't suggest that we
have separate translations for fr_CA, fr_CH, fr_FR, just a single 'fr'
would be fine.

We do need to be careful here; people are rightfully sensitive about
being incorrectly grouped together.  If possible we should find a
standard to follow that's been defined by experts in these matters.
https://en.wikipedia.org/wiki/IETF_language_tag may be a good place to
start looking.

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Akira Yokosawa]

On 2022/10/17 23:41, Matthew Wilcox wrote:
> On Sat, Oct 15, 2022 at 01:06:36PM +0900, Akira Yokosawa wrote:
>> Hi,
>> Minor nit on language code.
>>
>> On Fri, 14 Oct 2022 09:24:53 -0500, Carlos Bilbao wrote:
>>> Start the process of translating kernel documentation to Spanish. Create
>>> sp_SP/ and include an index and a disclaimer, following the approach of
>>> prior translations. Add Carlos Bilbao as MAINTAINER of this translation
>>> effort.
>> IIUC, the language code for "Spanish (Spain)" should be "es-ES", as is
>> listed at e.g., http://www.lingoes.net/en/translator/langcode.htm.
>>
>> The other translations use directory names found in the table, with
>> "-" replaced with "_".  It would be better to be consistent.
> 
> I don't know what standard we're actually following.  RFC5646 suggests
> simply using "es", with "es-419" for Latin America specialisation or
> "es-ES" for Spain.  I don't know how much variation there is between
> different Spanish dialects for technical documents; as I understand it,
> it's worth supporting two dialects of Chinese, but we merrily mix &
> match en_US and en_GB spellings.  Similarly, I wouldn't suggest that we
> have separate translations for fr_CA, fr_CH, fr_FR, just a single 'fr'
> would be fine.
> 
> We do need to be careful here; people are rightfully sensitive about
> being incorrectly grouped together.  If possible we should find a
> standard to follow that's been defined by experts in these matters.
> https://en.wikipedia.org/wiki/IETF_language_tag may be a good place to
> start looking.

I think generic "es" is OK, especially if "es_ES" can have such a
negative connotation to some. I just wanted to point out "sp_SP"
looks wrong.

Carlos, if you go the "es" way, it would be better to mention the
reason of the choice in the Changelog for future reference.

Subdirectories "ja_JP", "ko_KR", and "zh_CN" were added under
Documentation/ way back in 2007 (v2.6.23).

As you might see, two of the three language codes needed region
distinction and they were reasonable choices at the time.

        Thanks, Akira

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Carlos Bilbao]

On 10/17/22 21:36, Akira Yokosawa wrote:

> On 2022/10/17 23:41, Matthew Wilcox wrote:
>> On Sat, Oct 15, 2022 at 01:06:36PM +0900, Akira Yokosawa wrote:
>>> Hi,
>>> Minor nit on language code.
>>>
>>> On Fri, 14 Oct 2022 09:24:53 -0500, Carlos Bilbao wrote:
>>>> Start the process of translating kernel documentation to Spanish. Create
>>>> sp_SP/ and include an index and a disclaimer, following the approach of
>>>> prior translations. Add Carlos Bilbao as MAINTAINER of this translation
>>>> effort.
>>> IIUC, the language code for "Spanish (Spain)" should be "es-ES", as is
>>> listed at e.g., https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.lingoes.net%2Fen%2Ftranslator%2Flangcode.htm&data=05%7C01%7Ccarlos.bilbao%40amd.com%7C44c226d534f44b4afc1f08dab0b1893b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638016573808784843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bTm9yjEtum2LkTFkN1kZphytfVKN9Si2Ypk7j6s%2FaVw%3D&reserved=0.
>>>
>>> The other translations use directory names found in the table, with
>>> "-" replaced with "_".  It would be better to be consistent.
>> I don't know what standard we're actually following.  RFC5646 suggests
>> simply using "es", with "es-419" for Latin America specialisation or
>> "es-ES" for Spain.  I don't know how much variation there is between
>> different Spanish dialects for technical documents; as I understand it,
>> it's worth supporting two dialects of Chinese, but we merrily mix &
>> match en_US and en_GB spellings.  Similarly, I wouldn't suggest that we
>> have separate translations for fr_CA, fr_CH, fr_FR, just a single 'fr'
>> would be fine.
>>
>> We do need to be careful here; people are rightfully sensitive about
>> being incorrectly grouped together.  If possible we should find a
>> standard to follow that's been defined by experts in these matters.
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FIETF_language_tag&data=05%7C01%7Ccarlos.bilbao%40amd.com%7C44c226d534f44b4afc1f08dab0b1893b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638016573808784843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3T9bPQzcj9hEuZiPkjIU%2BPCEaxAivgaNKZ2gL5m3OQA%3D&reserved=0 may be a good place to
>> start looking.
> I think generic "es" is OK, especially if "es_ES" can have such a
> negative connotation to some. I just wanted to point out "sp_SP"
> looks wrong.
>
> Carlos, if you go the "es" way, it would be better to mention the
> reason of the choice in the Changelog for future reference.
>
> Subdirectories "ja_JP", "ko_KR", and "zh_CN" were added under
> Documentation/ way back in 2007 (v2.6.23).
>
> As you might see, two of the three language codes needed region
> distinction and they were reasonable choices at the time.
>
>          Thanks, Akira

Answering to Akira and Matthew below. Thanks to both for valuable feedback.

I made the conscious choice of not using es_ES, because as mentioned, it
references a standard that I don’t intend to follow myself or enforce on
Spanish translations. es_ES is a standard that comes from “Esp”-aña (Spain,
the country) whereas “sp_SP” is as in "Sp"-anish, the language, not the
country. Regarding this, I took the liberty of adding an extra paragraph to
index.rs. I would translate it to English like:

"Many countries speak Spanish, each one with its own culture, expressions,
and sometimes significant grammatical differences. The translators are free
to use the version of Spanish which they are most comfortable with. In
principle, these small differences should not pose a great barrier for
speakers of different versions of Spanish, albeit in case of doubt, you can
ask the maintainers."

I also opted for not using es_ES due to its geographical connotations. If
someone from Peru, Mexico, Argentina, … submits a translation tomorrow, I
would review it and we would understand each other just fine. Even within
“Spain” there are many dialects and things change within regions. I
reiterate that all dialects should be allowed in this directory.

Fortunately for us, versions of Spanish differ much more in spoken form
than they do when written. This does not happen between traditional and
simplified Chinese.

On top of everything else, using locale es_ES may imply that spell checks
on that directory using the locale es_ES would be clean, but this is very
far from reality, among other things, because all the English terms we
inherit regarding computers. As Miguel Ojeda pointed out somewhere in this
thread, there are terms that is better if we do not translate, to favor
understanding of code/other documents.

I will update the corresponding commit message to clarify why we are using
es_ES format in this particular case.

Best regards,
Carlos

Re: [PATCH v2 0/2] Documentation: Start Spanish translation and include HOWTO

[Carlos Bilbao]

On 10/14/22 22:40, Bagas Sanjaya wrote:

> On Fri, Oct 14, 2022 at 09:24:52AM -0500, Carlos Bilbao wrote:
>>    Documentation/translations/index.rst          |   1 +
>>    .../translations/sp_SP/disclaimer-sp.rst      |   6 +
>>    Documentation/translations/sp_SP/howto.rst    | 617 ++++++++++++++++++
>>    Documentation/translations/sp_SP/index.rst    |  80 +++
>>    MAINTAINERS                                   |   5 +
>>    5 files changed, 709 insertions(+)
>>    create mode 100644 Documentation/translations/sp_SP/disclaimer-sp.rst
>>    create mode 100644 Documentation/translations/sp_SP/howto.rst
>>    create mode 100644 Documentation/translations/sp_SP/index.rst
> Why not es_ES locale slug instead?

Just answered to this in different thread within patch set :)

Cheers,

Carlos

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Matthew Wilcox]

On Mon, Oct 24, 2022 at 08:40:42AM -0500, Carlos Bilbao wrote:
> > > I don't know what standard we're actually following.  RFC5646 suggests
> > > simply using "es", with "es-419" for Latin America specialisation or
> > > "es-ES" for Spain.  I don't know how much variation there is between
> > > different Spanish dialects for technical documents; as I understand it,
> > > it's worth supporting two dialects of Chinese, but we merrily mix &
> > > match en_US and en_GB spellings.  Similarly, I wouldn't suggest that we
> > > have separate translations for fr_CA, fr_CH, fr_FR, just a single 'fr'
> > > would be fine.
> > > 
> > > We do need to be careful here; people are rightfully sensitive about
> > > being incorrectly grouped together.  If possible we should find a
> > > standard to follow that's been defined by experts in these matters.
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FIETF_language_tag&data=05%7C01%7Ccarlos.bilbao%40amd.com%7C44c226d534f44b4afc1f08dab0b1893b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638016573808784843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3T9bPQzcj9hEuZiPkjIU%2BPCEaxAivgaNKZ2gL5m3OQA%3D&reserved=0 may be a good place to
> > > start looking.
> > I think generic "es" is OK, especially if "es_ES" can have such a
> > negative connotation to some. I just wanted to point out "sp_SP"
> > looks wrong.
> > 
> > Carlos, if you go the "es" way, it would be better to mention the
> > reason of the choice in the Changelog for future reference.
> > 
> > Subdirectories "ja_JP", "ko_KR", and "zh_CN" were added under
> > Documentation/ way back in 2007 (v2.6.23).
> > 
> > As you might see, two of the three language codes needed region
> > distinction and they were reasonable choices at the time.
> > 
> >          Thanks, Akira
> 
> Answering to Akira and Matthew below. Thanks to both for valuable feedback.
> 
> I made the conscious choice of not using es_ES, because as mentioned, it
> references a standard that I don’t intend to follow myself or enforce on
> Spanish translations. es_ES is a standard that comes from “Esp”-aña (Spain,
> the country) whereas “sp_SP” is as in "Sp"-anish, the language, not the
> country. Regarding this, I took the liberty of adding an extra paragraph to
> index.rs. I would translate it to English like:
> 
> "Many countries speak Spanish, each one with its own culture, expressions,
> and sometimes significant grammatical differences. The translators are free
> to use the version of Spanish which they are most comfortable with. In
> principle, these small differences should not pose a great barrier for
> speakers of different versions of Spanish, albeit in case of doubt, you can
> ask the maintainers."
> 
> I also opted for not using es_ES due to its geographical connotations. If
> someone from Peru, Mexico, Argentina, … submits a translation tomorrow, I
> would review it and we would understand each other just fine. Even within
> “Spain” there are many dialects and things change within regions. I
> reiterate that all dialects should be allowed in this directory.
> 
> Fortunately for us, versions of Spanish differ much more in spoken form
> than they do when written. This does not happen between traditional and
> simplified Chinese.
> 
> On top of everything else, using locale es_ES may imply that spell checks
> on that directory using the locale es_ES would be clean, but this is very
> far from reality, among other things, because all the English terms we
> inherit regarding computers. As Miguel Ojeda pointed out somewhere in this
> thread, there are terms that is better if we do not translate, to favor
> understanding of code/other documents.
> 
> I will update the corresponding commit message to clarify why we are using
> es_ES format in this particular case.

I think we're better off following BCP 47:
https://www.rfc-editor.org/info/bcp47 rather than the libc locale format.
That will imply renaming it_IT to simply "it", ja_JP to "ja" and
ko_KR to "ko".  The two Chinese translations we have might be called
"zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs
Simplified script.  If they really are region based, then they'd be
zh-CN and zh-TW.

I think you're right to conflate all dialects of Spanish together, just
as we do all dialects of English.

Jon, this feels like policy you should be setting.  Are you on board
with this, or do you want to retain the mandatory geography tag that
we've been using up to now?

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Miguel Ojeda]

On Mon, Oct 24, 2022 at 3:40 PM Carlos Bilbao <carlos.bilbao@amd.com> wrote:
>
> Fortunately for us, versions of Spanish differ much more in spoken form
> than they do when written.

Agreed: in Spanish, the differences, in particular in formal/technical
texts, are very minor.

Cheers,
Miguel

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Jonathan Corbet]

[Adding some of the other folks interested in translations]

Matthew Wilcox <willy@infradead.org> writes:

> I think we're better off following BCP 47:
> https://www.rfc-editor.org/info/bcp47 rather than the libc locale format.
> That will imply renaming it_IT to simply "it", ja_JP to "ja" and
> ko_KR to "ko".  The two Chinese translations we have might be called
> "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs
> Simplified script.  If they really are region based, then they'd be
> zh-CN and zh-TW.
>
> I think you're right to conflate all dialects of Spanish together, just
> as we do all dialects of English.
>
> Jon, this feels like policy you should be setting.  Are you on board
> with this, or do you want to retain the mandatory geography tag that
> we've been using up to now?

I want to go hide somewhere :)

I'd kind of prefer to avoid renaming the existing translations, as that
is sure to create a certain amount of short-term pain.  But I guess we
could do that if the benefit somehow seems worth it.

Of course, if we're thrashing things, we could also just call them
"Italian" (or "Italiano"), "Chinese", and so on.  I don't *think*
there's a need for the names to be machine-readable.  We should stick
with ASCII for these names just to help those of us who can't type in
other scripts.

If asked to set a policy today, my kneejerk reaction would be to leave
things as they are just to avoid a bunch of churn.  But I don't have a
strong opinion on how this naming should actually be done, as long as we
can pick something and be happy with it thereafter.  What do the
translation maintainers think?

Thanks,

jon

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Jonathan Corbet]

Resending without the screwy address that my mailer decided to put in
for Alex, sorry for the noise.

Jonathan Corbet <corbet@lwn.net> writes:

> [Adding some of the other folks interested in translations]
>
> Matthew Wilcox <willy@infradead.org> writes:
>
>> I think we're better off following BCP 47:
>> https://www.rfc-editor.org/info/bcp47 rather than the libc locale format.
>> That will imply renaming it_IT to simply "it", ja_JP to "ja" and
>> ko_KR to "ko".  The two Chinese translations we have might be called
>> "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs
>> Simplified script.  If they really are region based, then they'd be
>> zh-CN and zh-TW.
>>
>> I think you're right to conflate all dialects of Spanish together, just
>> as we do all dialects of English.
>>
>> Jon, this feels like policy you should be setting.  Are you on board
>> with this, or do you want to retain the mandatory geography tag that
>> we've been using up to now?
>
> I want to go hide somewhere :)
>
> I'd kind of prefer to avoid renaming the existing translations, as that
> is sure to create a certain amount of short-term pain.  But I guess we
> could do that if the benefit somehow seems worth it.
>
> Of course, if we're thrashing things, we could also just call them
> "Italian" (or "Italiano"), "Chinese", and so on.  I don't *think*
> there's a need for the names to be machine-readable.  We should stick
> with ASCII for these names just to help those of us who can't type in
> other scripts.
>
> If asked to set a policy today, my kneejerk reaction would be to leave
> things as they are just to avoid a bunch of churn.  But I don't have a
> strong opinion on how this naming should actually be done, as long as we
> can pick something and be happy with it thereafter.  What do the
> translation maintainers think?
>
> Thanks,
>
> jon

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Carlos Bilbao]

On 10/24/22 10:31, Jonathan Corbet wrote:
> Resending without the screwy address that my mailer decided to put in
> for Alex, sorry for the noise.
>
> Jonathan Corbet <corbet@lwn.net> writes:
>
>> [Adding some of the other folks interested in translations]
>>
>> Matthew Wilcox <willy@infradead.org> writes:
>>
>>> I think we're better off following BCP 47:
>>> https://www.rfc-editor.org/info/bcp47 rather than the libc locale format.
>>> That will imply renaming it_IT to simply "it", ja_JP to "ja" and
>>> ko_KR to "ko".  The two Chinese translations we have might be called
>>> "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs
>>> Simplified script.  If they really are region based, then they'd be
>>> zh-CN and zh-TW.
>>>
>>> I think you're right to conflate all dialects of Spanish together, just
>>> as we do all dialects of English.
>>>
>>> Jon, this feels like policy you should be setting.  Are you on board
>>> with this, or do you want to retain the mandatory geography tag that
>>> we've been using up to now?
>> I want to go hide somewhere :)
>>
>> I'd kind of prefer to avoid renaming the existing translations, as that
>> is sure to create a certain amount of short-term pain.  But I guess we
>> could do that if the benefit somehow seems worth it.
>>
>> Of course, if we're thrashing things, we could also just call them
>> "Italian" (or "Italiano"), "Chinese", and so on.  I don't *think*
>> there's a need for the names to be machine-readable.  We should stick
>> with ASCII for these names just to help those of us who can't type in
>> other scripts.
>>
>> If asked to set a policy today, my kneejerk reaction would be to leave
>> things as they are just to avoid a bunch of churn.  But I don't have a
>> strong opinion on how this naming should actually be done, as long as we
>> can pick something and be happy with it thereafter.  What do the
>> translation maintainers think?
>>
>> Thanks,
>>
>> jon

 From the perspective of the target audience (someone that wants to read
translated documentation) the name of the directories do not make any
difference; index.rst lists them in human readable format (e.g. "Traduzione
italiana").

It would make sense renaming if there was confusion among developers, but
there isn't.

For these reasons, and for the obvious inconvenience of renaming things back
and forth, I would say do not worry about it, Jon.

Thanks,
Carlos

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[Alex Shi]

On Mon, Oct 24, 2022 at 11:31 PM Jonathan Corbet <corbet@lwn.net> wrote:
>
>
> Resending without the screwy address that my mailer decided to put in
> for Alex, sorry for the noise.

Thanks for having me.
I am neutral about the change, and prefer less churn for code.
But if we have to, zh_hant/hans is better then CN and TW to comfort
other regions, like zh_SG, zh_HK etc.

Thanks
Alex

>
> Jonathan Corbet <corbet@lwn.net> writes:
>
> > [Adding some of the other folks interested in translations]
> >
> > Matthew Wilcox <willy@infradead.org> writes:
> >
> >> I think we're better off following BCP 47:
> >> https://www.rfc-editor.org/info/bcp47 rather than the libc locale format.
> >> That will imply renaming it_IT to simply "it", ja_JP to "ja" and
> >> ko_KR to "ko".  The two Chinese translations we have might be called
> >> "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs
> >> Simplified script.  If they really are region based, then they'd be
> >> zh-CN and zh-TW.
> >>
> >> I think you're right to conflate all dialects of Spanish together, just
> >> as we do all dialects of English.
> >>
> >> Jon, this feels like policy you should be setting.  Are you on board
> >> with this, or do you want to retain the mandatory geography tag that
> >> we've been using up to now?
> >
> > I want to go hide somewhere :)
> >
> > I'd kind of prefer to avoid renaming the existing translations, as that
> > is sure to create a certain amount of short-term pain.  But I guess we
> > could do that if the benefit somehow seems worth it.
> >
> > Of course, if we're thrashing things, we could also just call them
> > "Italian" (or "Italiano"), "Chinese", and so on.  I don't *think*
> > there's a need for the names to be machine-readable.  We should stick
> > with ASCII for these names just to help those of us who can't type in
> > other scripts.
> >
> > If asked to set a policy today, my kneejerk reaction would be to leave
> > things as they are just to avoid a bunch of churn.  But I don't have a
> > strong opinion on how this naming should actually be done, as long as we
> > can pick something and be happy with it thereafter.  What do the
> > translation maintainers think?
> >
> > Thanks,
> >
> > jon

Re: [PATCH v2 1/2] Documentation: Start translations to Spanish

[YanTeng Si]

在 2022/10/25 19:05, Alex Shi 写道:
> On Mon, Oct 24, 2022 at 11:31 PM Jonathan Corbet <corbet@lwn.net> wrote:
>>
>> Resending without the screwy address that my mailer decided to put in
>> for Alex, sorry for the noise.
> Thanks for having me.
> I am neutral about the change, and prefer less churn for code.
> But if we have to, zh_hant/hans is better then CN and TW to comfort
> other regions, like zh_SG, zh_HK etc.

Same here!

 >_<


Thanks,

Yanteng

>
> Thanks
> Alex
>
>> Jonathan Corbet <corbet@lwn.net> writes:
>>
>>> [Adding some of the other folks interested in translations]
>>>
>>> Matthew Wilcox <willy@infradead.org> writes:
>>>
>>>> I think we're better off following BCP 47:
>>>> https://www.rfc-editor.org/info/bcp47 rather than the libc locale format.
>>>> That will imply renaming it_IT to simply "it", ja_JP to "ja" and
>>>> ko_KR to "ko".  The two Chinese translations we have might be called
>>>> "zh-Hant" and "zh-Hans", if the distinction is purely Traditional vs
>>>> Simplified script.  If they really are region based, then they'd be
>>>> zh-CN and zh-TW.
>>>>
>>>> I think you're right to conflate all dialects of Spanish together, just
>>>> as we do all dialects of English.
>>>>
>>>> Jon, this feels like policy you should be setting.  Are you on board
>>>> with this, or do you want to retain the mandatory geography tag that
>>>> we've been using up to now?
>>> I want to go hide somewhere :)
>>>
>>> I'd kind of prefer to avoid renaming the existing translations, as that
>>> is sure to create a certain amount of short-term pain.  But I guess we
>>> could do that if the benefit somehow seems worth it.
>>>
>>> Of course, if we're thrashing things, we could also just call them
>>> "Italian" (or "Italiano"), "Chinese", and so on.  I don't *think*
>>> there's a need for the names to be machine-readable.  We should stick
>>> with ASCII for these names just to help those of us who can't type in
>>> other scripts.
>>>
>>> If asked to set a policy today, my kneejerk reaction would be to leave
>>> things as they are just to avoid a bunch of churn.  But I don't have a
>>> strong opinion on how this naming should actually be done, as long as we
>>> can pick something and be happy with it thereafter.  What do the
>>> translation maintainers think?
>>>
>>> Thanks,
>>>
>>> jon