[PATCH v2 0/3] docs: sp_SP: Add Rust documentation section

[PATCH v2 0/3] docs: sp_SP: Add Rust documentation section

[Edwin Toribio]

This series provides the Spanish translation for the Rust documentation
section in the Linux kernel, including the quick-start guide, general 
information, and coding guidelines.

In this second version, all documents have been unified and updated to
comply with the feedback provided regarding style and technical accuracy.

Changes in v2:
- Added new translations: coding-guidelines.rst and index.rst.
- Standardized the use of "p. ej." abbreviation throughout all files.
- Fixed the Hacking section truncation in quick-start.rst.

Edwin Toribio (3):
  docs: sp_SP: Add Spanish translation for Rust quick-start
  docs: sp_SP: Add Spanish translation for Rust general information
  docs: sp_SP: Add Spanish translation for Rust coding guidelines

 .../sp_SP/rust/coding-guidelines.rst          | 543 ++++++++++++++++++
 .../sp_SP/rust/general-information.rst        | 178 ++++++
 .../translations/sp_SP/rust/index.rst         |  45 ++
 .../translations/sp_SP/rust/quick-start.rst   | 384 +++++++++++++
 4 files changed, 1150 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/rust/coding-guidelines.rst
 create mode 100644 Documentation/translations/sp_SP/rust/general-information.rst
 create mode 100644 Documentation/translations/sp_SP/rust/index.rst
 create mode 100644 Documentation/translations/sp_SP/rust/quick-start.rst

-- 
2.53.0

[PATCH v2 1/3] docs: sp_SP: Add Spanish translation for Rust quick-start

[Edwin Toribio]

Signed-off-by: Edwin Toribio <edwin.toribio.j@gmail.com>
---
 .../translations/sp_SP/rust/quick-start.rst   | 384 ++++++++++++++++++
 1 file changed, 384 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/rust/quick-start.rst

diff --git a/Documentation/translations/sp_SP/rust/quick-start.rst b/Documentation/translations/sp_SP/rust/quick-start.rst
new file mode 100644
index 000000000..276b81971
--- /dev/null
+++ b/Documentation/translations/sp_SP/rust/quick-start.rst
@@ -0,0 +1,384 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-sp.rst
+
+:Original: Documentation/rust/quick-start.rst
+:Translator: Edwin Toribio <edwin.toribio.j@gmail.com>
+
+.. _sp_rust_quick_start:
+
+Guía de inicio rápido
+=====================
+
+Este documento describe cómo empezar con el desarrollo del kernel en Rust.
+
+Existen varias formas de instalar el conjunto de herramientas (toolchain) de Rust
+necesario para el desarrollo del kernel. Una forma sencilla es utilizar los
+paquetes de su distribución de Linux si son adecuados; la primera sección a
+continuación explica este enfoque. Una ventaja de este método es que,
+normalmente, la distribución hará coincidir el LLVM utilizado por Rust y Clang.
+
+Otra forma es utilizar las versiones estables precompiladas de LLVM+Rust
+proporcionadas en `kernel.org <https://kernel.org/pub/tools/llvm/rust/>`_.
+Estas son las mismas herramientas de LLVM ligeras y rápidas de
+:ref:`Obtener LLVM <getting_llvm>` con versiones de Rust añadidas que son
+compatibles con Rust para Linux. Se proporcionan dos conjuntos: el "LLVM más
+reciente" (latest LLVM) y el "LLVM coincidente" (matching LLVM) (consulte el
+enlace para más información).
+
+Alternativamente, las dos secciones siguientes de "Requisitos" explican cada
+componente y cómo instalarlos a través de ``rustup``, los instaladores
+independientes de Rust y/o compilándolos.
+
+El resto del documento explica otros aspectos sobre cómo empezar.
+
+
+Distribuciones
+--------------
+
+Arch Linux
+**********
+
+Arch Linux proporciona versiones recientes de Rust y, por lo tanto, debería
+funcionar directamente, p. ej.::
+
+    pacman -S rust rust-src rust-bindgen
+
+
+Debian
+******
+
+Debian 13 (Trixie), así como Testing y Debian Unstable (Sid) proporcionan
+versiones recientes de Rust y, por lo tanto, deberían funcionar directamente, p. ej.::
+
+    apt install rustc rust-src bindgen rustfmt rust-clippy
+
+
+Fedora Linux
+************
+
+Fedora Linux proporciona versiones recientes de Rust y, por lo tanto, debería
+funcionar directamente, p. ej.::
+
+    dnf install rust rust-src bindgen-cli rustfmt clippy
+
+
+Gentoo Linux
+************
+
+Gentoo Linux (y especialmente la rama de pruebas) proporciona versiones
+recientes de Rust y, por lo tanto, debería funcionar directamente, p. ej.::
+
+    USE='rust-src rustfmt clippy' emerge dev-lang/rust dev-util/bindgen
+
+Es posible que sea necesario configurar ``LIBCLANG_PATH``.
+
+
+Nix
+***
+
+Nix (canal unstable) proporciona versiones recientes de Rust y, por lo tanto,
+debería funcionar directamente, p. ej.::
+
+    { pkgs ? import <nixpkgs> {} }:
+    pkgs.mkShell {
+      nativeBuildInputs = with pkgs; [ rustc rust-bindgen rustfmt clippy ];
+      RUST_LIB_SRC = "${pkgs.rust.packages.stable.rustPlatform.rustLibSrc}";
+    }
+
+
+openSUSE
+********
+
+openSUSE Slowroll y openSUSE Tumbleweed proporcionan versiones recientes de Rust
+y, por lo tanto, deberían funcionar directamente, p. ej.::
+
+    zypper install rust rust1.79-src rust-bindgen clang
+
+
+Ubuntu
+******
+
+25.04
+~~~~~
+
+Las versiones más recientes de Ubuntu proporcionan versiones recientes de Rust
+y, por lo tanto, deberían funcionar directamente, p. ej.::
+
+    apt install rustc rust-src bindgen rustfmt rust-clippy
+
+Además, es necesario configurar ``RUST_LIB_SRC``, p. ej.::
+
+    RUST_LIB_SRC=/usr/src/rustc-$(rustc --version | cut -d' ' -f2)/library
+
+Para mayor comodidad, ``RUST_LIB_SRC`` puede exportarse al entorno global.
+
+
+24.04 LTS y anteriores
+~~~~~~~~~~~~~~~~~~~~~~
+
+Aunque Ubuntu 24.04 LTS y versiones anteriores todavía proporcionan versiones
+recientes de Rust, requieren que se establezca alguna configuración adicional,
+utilizando los paquetes con versión, p. ej.::
+
+    apt install rustc-1.80 rust-1.80-src bindgen-0.65 rustfmt-1.80 \
+        rust-1.80-clippy
+    ln -s /usr/lib/rust-1.80/bin/rustfmt /usr/bin/rustfmt-1.80
+    ln -s /usr/lib/rust-1.80/bin/clippy-driver /usr/bin/clippy-driver-1.80
+
+Ninguno de estos paquetes establece sus herramientas como predeterminadas; por
+lo tanto, deben especificarse explícitamente, p. ej.::
+
+    make LLVM=1 RUSTC=rustc-1.80 RUSTDOC=rustdoc-1.80 RUSTFMT=rustfmt-1.80 \
+        CLIPPY_DRIVER=clippy-driver-1.80 BINDGEN=bindgen-0.65
+
+Alternativamente, modifique la variable ``PATH`` para colocar los binarios de
+Rust 1.80 primero y establezca ``bindgen`` como predeterminado, p. ej.::
+
+    PATH=/usr/lib/rust-1.80/bin:$PATH
+    update-alternatives --install /usr/bin/bindgen bindgen \
+        /usr/bin/bindgen-0.65 100
+    update-alternatives --set bindgen /usr/bin/bindgen-0.65
+
+``RUST_LIB_SRC`` debe configurarse cuando se usan los paquetes con versión, p. ej.::
+
+    RUST_LIB_SRC=/usr/src/rustc-$(rustc-1.80 --version | cut -d' ' -f2)/library
+
+Para mayor comodidad, ``RUST_LIB_SRC`` puede exportarse al entorno global.
+
+Además, ``bindgen-0.65`` está disponible en versiones más nuevas (24.04 LTS y
+24.10), pero puede no estar disponible en las más antiguas (20.04 LTS y 22.04 LTS),
+por lo que es posible que sea necesario compilar ``bindgen`` manualmente
+(consulte más abajo).
+
+
+Requisitos: Compilación
+-----------------------
+
+Esta sección explica cómo obtener las herramientas necesarias para la compilación.
+
+Para comprobar fácilmente si se cumplen los requisitos, se puede utilizar el
+siguiente objetivo (target)::
+
+    make LLVM=1 rustavailable
+
+Esto activa la misma lógica utilizada por Kconfig para determinar si debe
+habilitarse ``RUST_IS_AVAILABLE``; pero también explica por qué no en caso
+de que así sea.
+
+
+rustc
+*****
+
+Se requiere una versión reciente del compilador de Rust.
+
+Si se está utilizando ``rustup``, entre en el directorio de compilación del
+kernel (o use el argumento ``--path=<build-dir>`` para el subcomando ``set``)
+y ejecute, por ejemplo::
+
+    rustup override set stable
+
+Esto configurará su directorio de trabajo para usar la versión dada de
+``rustc`` sin afectar a su conjunto de herramientas predeterminado.
+
+Tenga en cuenta que la anulación (override) se aplica al directorio de trabajo
+actual (y sus subdirectorios).
+
+Si no está utilizando ``rustup``, obtenga un instalador independiente de:
+
+    https://forge.rust-lang.org/infra/other-installation-methods.html#standalone
+
+
+Código fuente de la biblioteca estándar de Rust
+***********************************************
+
+Se requiere el código fuente de la biblioteca estándar de Rust porque el sistema
+de compilación compilará de forma cruzada ``core``.
+
+Si se está utilizando ``rustup``, ejecute::
+
+    rustup component add rust-src
+
+Los componentes se instalan por conjunto de herramientas, por lo que actualizar
+la versión del compilador de Rust más adelante requiere volver a añadir el
+componente.
+
+De lo contrario, si se utiliza un instalador independiente, el árbol de fuentes
+de Rust puede descargarse en la carpeta de instalación del conjunto de
+herramientas::
+
+    curl -L "https://static.rust-lang.org/dist/rust-src-$(rustc --version | cut -d' ' -f2).tar.gz" |
+        tar -xzf - -C "$(rustc --print sysroot)/lib" \
+        "rust-src-$(rustc --version | cut -d' ' -f2)/rust-src/lib/" \
+        --strip-components=3
+
+En este caso, actualizar la versión del compilador de Rust más adelante requiere
+actualizar manualmente el árbol de fuentes (esto se puede hacer eliminando
+``$(rustc --print sysroot)/lib/rustlib/src/rust`` y volviendo a ejecutar el
+comando anterior).
+
+
+libclang
+********
+
+``libclang`` (parte de LLVM) es utilizado por ``bindgen`` para entender el
+código C en el kernel, lo que significa que LLVM debe estar instalado; al igual
+que cuando el kernel se compila con ``LLVM=1``.
+
+Es probable que las distribuciones de Linux tengan una adecuada disponible, por
+lo que es mejor comprobarlo primero.
+
+También hay algunos binarios para varios sistemas y arquitecturas subidos a:
+
+    https://releases.llvm.org/download.html
+
+De lo contrario, compilar LLVM lleva bastante tiempo, pero no es un proceso
+complejo:
+
+    https://llvm.org/docs/GettingStarted.html#getting-the-source-code-and-building-llvm
+
+Consulte Documentation/kbuild/llvm.rst para obtener más información y otras
+formas de obtener versiones precompiladas y paquetes de distribuciones.
+
+
+bindgen
+*******
+
+Los vínculos (bindings) con la parte de C del kernel se generan en tiempo de
+compilación utilizando la herramienta ``bindgen``.
+
+Instálela, por ejemplo, mediante (tenga en cuenta que esto descargará y
+compilará la herramienta desde el código fuente)::
+
+    cargo install --locked bindgen-cli
+
+``bindgen`` utiliza la caja (crate) ``clang-sys`` para encontrar un
+``libclang`` adecuado (que puede estar vinculado estáticamente, dinámicamente
+o cargado en tiempo de ejecución). Por defecto, el comando ``cargo`` anterior
+producirá un binario ``bindgen`` que cargará ``libclang`` en tiempo de
+ejecución. Si no se encuentra (o si se debe usar un ``libclang`` diferente al
+encontrado), el proceso se puede ajustar, p. ej. utilizando la variable de entorno
+``LIBCLANG_PATH``. Para más detalles, consulte la documentación de
+``clang-sys`` en:
+
+    https://github.com/KyleMayes/clang-sys#linking
+
+    https://github.com/KyleMayes/clang-sys#environment-variables
+
+
+Requisitos: Desarrollo
+----------------------
+
+Esta sección explica cómo obtener las herramientas necesarias para el
+desarrollo. Es decir, no son necesarias cuando solo se compila el kernel.
+
+
+rustfmt
+*******
+
+La herramienta ``rustfmt`` se utiliza para formatear automáticamente todo el
+código Rust del kernel, incluyendo los vínculos de C generados (para más
+detalles, consulte coding-guidelines.rst).
+
+Si se utiliza ``rustup``, su perfil ``default`` ya instala la herramienta, por
+lo que no es necesario hacer nada. Si se utiliza otro perfil, el componente
+puede instalarse manualmente::
+
+    rustup component add rustfmt
+
+Los instaladores independientes también vienen con ``rustfmt``.
+
+
+clippy
+******
+
+``clippy`` es un linter de Rust. Ejecutarlo proporciona advertencias
+adicionales para el código Rust. Se puede ejecutar pasando ``CLIPPY=1`` a
+``make`` (para más detalles, consulte general-information.rst).
+
+Si se utiliza ``rustup``, su perfil ``default`` ya instala la herramienta, por
+lo que no es necesario hacer nada. Si se utiliza otro perfil, el componente
+puede instalarse manualmente::
+
+    rustup component add clippy
+
+Los instaladores independientes también vienen con ``clippy``.
+
+
+rustdoc
+*******
+
+``rustdoc`` es la herramienta de documentación para Rust. Genera una atractiva
+documentación en HTML para el código Rust (para más detalles, consulte
+general-information.rst).
+
+``rustdoc`` también se utiliza para probar los ejemplos proporcionados en el
+código Rust documentado (llamados doctests o pruebas de documentación). El
+objetivo de Make ``rusttest`` utiliza esta función.
+
+Si se utiliza ``rustup``, todos los perfiles ya instalan la herramienta, por
+lo que no es necesario hacer nada.
+
+Los instaladores independientes también vienen con ``rustdoc``.
+
+
+rust-analyzer
+*************
+
+El servidor de lenguaje `rust-analyzer <https://rust-analyzer.github.io/>`_
+puede utilizarse con muchos editores para habilitar el resaltado de sintaxis,
+el completado, el salto a la definición y otras funciones.
+
+``rust-analyzer`` necesita un archivo de configuración, ``rust-project.json``,
+que puede generarse mediante el objetivo de Make ``rust-analyzer``::
+
+    make LLVM=1 rust-analyzer
+
+
+Configuración
+-------------
+
+El ``Rust support`` (``CONFIG_RUST``) debe habilitarse en el menú
+``General setup``. La opción solo se muestra si se encuentra un conjunto de
+herramientas de Rust adecuado (véase arriba), siempre que se cumplan los demás
+requisitos. A su vez, esto hará visibles el resto de las opciones que
+dependen de Rust.
+
+A continuación, vaya a::
+
+    Kernel hacking
+        -> Sample kernel code
+            -> Rust samples
+
+Y habilite algunos módulos de ejemplo, ya sea como integrados (built-in) o
+como cargables.
+
+
+Compilación
+-----------
+
+Compilar un kernel con un conjunto de herramientas LLVM completo es la
+configuración mejor soportada en este momento. Es decir::
+
+    make LLVM=1
+
+El uso de GCC también funciona para algunas configuraciones, pero es muy
+experimental en este momento.
+
+
+Hacking
+-------
+
+Para profundizar más, eche un vistazo al código fuente de los ejemplos en
+``samples/rust/``, al código de soporte de Rust bajo ``rust/`` y al menú
+``Rust hacking`` bajo ``Kernel hacking``.
+
+Si se utiliza GDB/Binutils y los símbolos de Rust no se decodifican (demangle)
+correctamente, la razón es que el conjunto de herramientas aún no soporta el
+nuevo esquema de decoración de nombres (mangling) v0 de Rust. Hay algunas
+soluciones:
+
+- Instalar una versión más reciente (GDB >= 10.2, Binutils >= 2.36).
+
+- Algunas versiones de GDB (p. ej. GDB 10.1 estándar) pueden utilizar los nombres
+  pre-decodificados incrustados en la información de depuración(``CONFIG_DEBUG_INFO``).
\ No newline at end of file
-- 
2.53.0

Re: [PATCH v2 1/3] docs: sp_SP: Add Spanish translation for Rust quick-start

[Carlos Bilbao]

On 3/4/26 12:07, Edwin Toribio wrote:

> Signed-off-by: Edwin Toribio <edwin.toribio.j@gmail.com>


  Signed-off-by: Carlos Bilbao <carlos.bilbao@kernel.org>


> ---
>   .../translations/sp_SP/rust/quick-start.rst   | 384 ++++++++++++++++++
>   1 file changed, 384 insertions(+)
>   create mode 100644 Documentation/translations/sp_SP/rust/quick-start.rst
>
> diff --git a/Documentation/translations/sp_SP/rust/quick-start.rst b/Documentation/translations/sp_SP/rust/quick-start.rst
> new file mode 100644
> index 000000000..276b81971
> --- /dev/null
> +++ b/Documentation/translations/sp_SP/rust/quick-start.rst
> @@ -0,0 +1,384 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +.. include:: ../disclaimer-sp.rst
> +
> +:Original: Documentation/rust/quick-start.rst
> +:Translator: Edwin Toribio <edwin.toribio.j@gmail.com>
> +
> +.. _sp_rust_quick_start:
> +
> +Guía de inicio rápido
> +=====================
> +
> +Este documento describe cómo empezar con el desarrollo del kernel en Rust.
> +
> +Existen varias formas de instalar el conjunto de herramientas (toolchain) de Rust
> +necesario para el desarrollo del kernel. Una forma sencilla es utilizar los
> +paquetes de su distribución de Linux si son adecuados; la primera sección a
> +continuación explica este enfoque. Una ventaja de este método es que,
> +normalmente, la distribución hará coincidir el LLVM utilizado por Rust y Clang.
> +
> +Otra forma es utilizar las versiones estables precompiladas de LLVM+Rust
> +proporcionadas en `kernel.org <https://kernel.org/pub/tools/llvm/rust/>`_.
> +Estas son las mismas herramientas de LLVM ligeras y rápidas de
> +:ref:`Obtener LLVM <getting_llvm>` con versiones de Rust añadidas que son
> +compatibles con Rust para Linux. Se proporcionan dos conjuntos: el "LLVM más
> +reciente" (latest LLVM) y el "LLVM coincidente" (matching LLVM) (consulte el
> +enlace para más información).
> +
> +Alternativamente, las dos secciones siguientes de "Requisitos" explican cada
> +componente y cómo instalarlos a través de ``rustup``, los instaladores
> +independientes de Rust y/o compilándolos.
> +
> +El resto del documento explica otros aspectos sobre cómo empezar.
> +
> +
> +Distribuciones
> +--------------
> +
> +Arch Linux
> +**********
> +
> +Arch Linux proporciona versiones recientes de Rust y, por lo tanto, debería
> +funcionar directamente, p. ej.::
> +
> +    pacman -S rust rust-src rust-bindgen
> +
> +
> +Debian
> +******
> +
> +Debian 13 (Trixie), así como Testing y Debian Unstable (Sid) proporcionan
> +versiones recientes de Rust y, por lo tanto, deberían funcionar directamente, p. ej.::
> +
> +    apt install rustc rust-src bindgen rustfmt rust-clippy
> +
> +
> +Fedora Linux
> +************
> +
> +Fedora Linux proporciona versiones recientes de Rust y, por lo tanto, debería
> +funcionar directamente, p. ej.::
> +
> +    dnf install rust rust-src bindgen-cli rustfmt clippy
> +
> +
> +Gentoo Linux
> +************
> +
> +Gentoo Linux (y especialmente la rama de pruebas) proporciona versiones
> +recientes de Rust y, por lo tanto, debería funcionar directamente, p. ej.::
> +
> +    USE='rust-src rustfmt clippy' emerge dev-lang/rust dev-util/bindgen
> +
> +Es posible que sea necesario configurar ``LIBCLANG_PATH``.
> +
> +
> +Nix
> +***
> +
> +Nix (canal unstable) proporciona versiones recientes de Rust y, por lo tanto,
> +debería funcionar directamente, p. ej.::
> +
> +    { pkgs ? import <nixpkgs> {} }:
> +    pkgs.mkShell {
> +      nativeBuildInputs = with pkgs; [ rustc rust-bindgen rustfmt clippy ];
> +      RUST_LIB_SRC = "${pkgs.rust.packages.stable.rustPlatform.rustLibSrc}";
> +    }
> +
> +
> +openSUSE
> +********
> +
> +openSUSE Slowroll y openSUSE Tumbleweed proporcionan versiones recientes de Rust
> +y, por lo tanto, deberían funcionar directamente, p. ej.::
> +
> +    zypper install rust rust1.79-src rust-bindgen clang
> +
> +
> +Ubuntu
> +******
> +
> +25.04
> +~~~~~
> +
> +Las versiones más recientes de Ubuntu proporcionan versiones recientes de Rust
> +y, por lo tanto, deberían funcionar directamente, p. ej.::
> +
> +    apt install rustc rust-src bindgen rustfmt rust-clippy
> +
> +Además, es necesario configurar ``RUST_LIB_SRC``, p. ej.::
> +
> +    RUST_LIB_SRC=/usr/src/rustc-$(rustc --version | cut -d' ' -f2)/library
> +
> +Para mayor comodidad, ``RUST_LIB_SRC`` puede exportarse al entorno global.
> +
> +
> +24.04 LTS y anteriores
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +Aunque Ubuntu 24.04 LTS y versiones anteriores todavía proporcionan versiones
> +recientes de Rust, requieren que se establezca alguna configuración adicional,
> +utilizando los paquetes con versión, p. ej.::
> +
> +    apt install rustc-1.80 rust-1.80-src bindgen-0.65 rustfmt-1.80 \
> +        rust-1.80-clippy
> +    ln -s /usr/lib/rust-1.80/bin/rustfmt /usr/bin/rustfmt-1.80
> +    ln -s /usr/lib/rust-1.80/bin/clippy-driver /usr/bin/clippy-driver-1.80
> +
> +Ninguno de estos paquetes establece sus herramientas como predeterminadas; por
> +lo tanto, deben especificarse explícitamente, p. ej.::
> +
> +    make LLVM=1 RUSTC=rustc-1.80 RUSTDOC=rustdoc-1.80 RUSTFMT=rustfmt-1.80 \
> +        CLIPPY_DRIVER=clippy-driver-1.80 BINDGEN=bindgen-0.65
> +
> +Alternativamente, modifique la variable ``PATH`` para colocar los binarios de
> +Rust 1.80 primero y establezca ``bindgen`` como predeterminado, p. ej.::
> +
> +    PATH=/usr/lib/rust-1.80/bin:$PATH
> +    update-alternatives --install /usr/bin/bindgen bindgen \
> +        /usr/bin/bindgen-0.65 100
> +    update-alternatives --set bindgen /usr/bin/bindgen-0.65
> +
> +``RUST_LIB_SRC`` debe configurarse cuando se usan los paquetes con versión, p. ej.::
> +
> +    RUST_LIB_SRC=/usr/src/rustc-$(rustc-1.80 --version | cut -d' ' -f2)/library
> +
> +Para mayor comodidad, ``RUST_LIB_SRC`` puede exportarse al entorno global.
> +
> +Además, ``bindgen-0.65`` está disponible en versiones más nuevas (24.04 LTS y
> +24.10), pero puede no estar disponible en las más antiguas (20.04 LTS y 22.04 LTS),
> +por lo que es posible que sea necesario compilar ``bindgen`` manualmente
> +(consulte más abajo).
> +
> +
> +Requisitos: Compilación
> +-----------------------
> +
> +Esta sección explica cómo obtener las herramientas necesarias para la compilación.
> +
> +Para comprobar fácilmente si se cumplen los requisitos, se puede utilizar el
> +siguiente objetivo (target)::
> +
> +    make LLVM=1 rustavailable
> +
> +Esto activa la misma lógica utilizada por Kconfig para determinar si debe
> +habilitarse ``RUST_IS_AVAILABLE``; pero también explica por qué no en caso
> +de que así sea.
> +
> +
> +rustc
> +*****
> +
> +Se requiere una versión reciente del compilador de Rust.
> +
> +Si se está utilizando ``rustup``, entre en el directorio de compilación del
> +kernel (o use el argumento ``--path=<build-dir>`` para el subcomando ``set``)
> +y ejecute, por ejemplo::
> +
> +    rustup override set stable
> +
> +Esto configurará su directorio de trabajo para usar la versión dada de
> +``rustc`` sin afectar a su conjunto de herramientas predeterminado.
> +
> +Tenga en cuenta que la anulación (override) se aplica al directorio de trabajo
> +actual (y sus subdirectorios).
> +
> +Si no está utilizando ``rustup``, obtenga un instalador independiente de:
> +
> +    https://forge.rust-lang.org/infra/other-installation-methods.html#standalone
> +
> +
> +Código fuente de la biblioteca estándar de Rust
> +***********************************************
> +
> +Se requiere el código fuente de la biblioteca estándar de Rust porque el sistema
> +de compilación compilará de forma cruzada ``core``.
> +
> +Si se está utilizando ``rustup``, ejecute::
> +
> +    rustup component add rust-src
> +
> +Los componentes se instalan por conjunto de herramientas, por lo que actualizar
> +la versión del compilador de Rust más adelante requiere volver a añadir el
> +componente.
> +
> +De lo contrario, si se utiliza un instalador independiente, el árbol de fuentes
> +de Rust puede descargarse en la carpeta de instalación del conjunto de
> +herramientas::
> +
> +    curl -L "https://static.rust-lang.org/dist/rust-src-$(rustc --version | cut -d' ' -f2).tar.gz" |
> +        tar -xzf - -C "$(rustc --print sysroot)/lib" \
> +        "rust-src-$(rustc --version | cut -d' ' -f2)/rust-src/lib/" \
> +        --strip-components=3
> +
> +En este caso, actualizar la versión del compilador de Rust más adelante requiere
> +actualizar manualmente el árbol de fuentes (esto se puede hacer eliminando
> +``$(rustc --print sysroot)/lib/rustlib/src/rust`` y volviendo a ejecutar el
> +comando anterior).
> +
> +
> +libclang
> +********
> +
> +``libclang`` (parte de LLVM) es utilizado por ``bindgen`` para entender el
> +código C en el kernel, lo que significa que LLVM debe estar instalado; al igual
> +que cuando el kernel se compila con ``LLVM=1``.
> +
> +Es probable que las distribuciones de Linux tengan una adecuada disponible, por
> +lo que es mejor comprobarlo primero.
> +
> +También hay algunos binarios para varios sistemas y arquitecturas subidos a:
> +
> +    https://releases.llvm.org/download.html
> +
> +De lo contrario, compilar LLVM lleva bastante tiempo, pero no es un proceso
> +complejo:
> +
> +    https://llvm.org/docs/GettingStarted.html#getting-the-source-code-and-building-llvm
> +
> +Consulte Documentation/kbuild/llvm.rst para obtener más información y otras
> +formas de obtener versiones precompiladas y paquetes de distribuciones.
> +
> +
> +bindgen
> +*******
> +
> +Los vínculos (bindings) con la parte de C del kernel se generan en tiempo de
> +compilación utilizando la herramienta ``bindgen``.
> +
> +Instálela, por ejemplo, mediante (tenga en cuenta que esto descargará y
> +compilará la herramienta desde el código fuente)::
> +
> +    cargo install --locked bindgen-cli
> +
> +``bindgen`` utiliza la caja (crate) ``clang-sys`` para encontrar un
> +``libclang`` adecuado (que puede estar vinculado estáticamente, dinámicamente
> +o cargado en tiempo de ejecución). Por defecto, el comando ``cargo`` anterior
> +producirá un binario ``bindgen`` que cargará ``libclang`` en tiempo de
> +ejecución. Si no se encuentra (o si se debe usar un ``libclang`` diferente al
> +encontrado), el proceso se puede ajustar, p. ej. utilizando la variable de entorno
> +``LIBCLANG_PATH``. Para más detalles, consulte la documentación de
> +``clang-sys`` en:
> +
> +    https://github.com/KyleMayes/clang-sys#linking
> +
> +    https://github.com/KyleMayes/clang-sys#environment-variables
> +
> +
> +Requisitos: Desarrollo
> +----------------------
> +
> +Esta sección explica cómo obtener las herramientas necesarias para el
> +desarrollo. Es decir, no son necesarias cuando solo se compila el kernel.
> +
> +
> +rustfmt
> +*******
> +
> +La herramienta ``rustfmt`` se utiliza para formatear automáticamente todo el
> +código Rust del kernel, incluyendo los vínculos de C generados (para más
> +detalles, consulte coding-guidelines.rst).
> +
> +Si se utiliza ``rustup``, su perfil ``default`` ya instala la herramienta, por
> +lo que no es necesario hacer nada. Si se utiliza otro perfil, el componente
> +puede instalarse manualmente::
> +
> +    rustup component add rustfmt
> +
> +Los instaladores independientes también vienen con ``rustfmt``.
> +
> +
> +clippy
> +******
> +
> +``clippy`` es un linter de Rust. Ejecutarlo proporciona advertencias
> +adicionales para el código Rust. Se puede ejecutar pasando ``CLIPPY=1`` a
> +``make`` (para más detalles, consulte general-information.rst).
> +
> +Si se utiliza ``rustup``, su perfil ``default`` ya instala la herramienta, por
> +lo que no es necesario hacer nada. Si se utiliza otro perfil, el componente
> +puede instalarse manualmente::
> +
> +    rustup component add clippy
> +
> +Los instaladores independientes también vienen con ``clippy``.
> +
> +
> +rustdoc
> +*******
> +
> +``rustdoc`` es la herramienta de documentación para Rust. Genera una atractiva
> +documentación en HTML para el código Rust (para más detalles, consulte
> +general-information.rst).
> +
> +``rustdoc`` también se utiliza para probar los ejemplos proporcionados en el
> +código Rust documentado (llamados doctests o pruebas de documentación). El
> +objetivo de Make ``rusttest`` utiliza esta función.
> +
> +Si se utiliza ``rustup``, todos los perfiles ya instalan la herramienta, por
> +lo que no es necesario hacer nada.
> +
> +Los instaladores independientes también vienen con ``rustdoc``.
> +
> +
> +rust-analyzer
> +*************
> +
> +El servidor de lenguaje `rust-analyzer <https://rust-analyzer.github.io/>`_
> +puede utilizarse con muchos editores para habilitar el resaltado de sintaxis,
> +el completado, el salto a la definición y otras funciones.
> +
> +``rust-analyzer`` necesita un archivo de configuración, ``rust-project.json``,
> +que puede generarse mediante el objetivo de Make ``rust-analyzer``::
> +
> +    make LLVM=1 rust-analyzer
> +
> +
> +Configuración
> +-------------
> +
> +El ``Rust support`` (``CONFIG_RUST``) debe habilitarse en el menú
> +``General setup``. La opción solo se muestra si se encuentra un conjunto de
> +herramientas de Rust adecuado (véase arriba), siempre que se cumplan los demás
> +requisitos. A su vez, esto hará visibles el resto de las opciones que
> +dependen de Rust.
> +
> +A continuación, vaya a::
> +
> +    Kernel hacking
> +        -> Sample kernel code
> +            -> Rust samples
> +
> +Y habilite algunos módulos de ejemplo, ya sea como integrados (built-in) o
> +como cargables.
> +
> +
> +Compilación
> +-----------
> +
> +Compilar un kernel con un conjunto de herramientas LLVM completo es la
> +configuración mejor soportada en este momento. Es decir::
> +
> +    make LLVM=1
> +
> +El uso de GCC también funciona para algunas configuraciones, pero es muy
> +experimental en este momento.
> +
> +
> +Hacking
> +-------
> +
> +Para profundizar más, eche un vistazo al código fuente de los ejemplos en
> +``samples/rust/``, al código de soporte de Rust bajo ``rust/`` y al menú
> +``Rust hacking`` bajo ``Kernel hacking``.
> +
> +Si se utiliza GDB/Binutils y los símbolos de Rust no se decodifican (demangle)
> +correctamente, la razón es que el conjunto de herramientas aún no soporta el
> +nuevo esquema de decoración de nombres (mangling) v0 de Rust. Hay algunas
> +soluciones:
> +
> +- Instalar una versión más reciente (GDB >= 10.2, Binutils >= 2.36).
> +
> +- Algunas versiones de GDB (p. ej. GDB 10.1 estándar) pueden utilizar los nombres
> +  pre-decodificados incrustados en la información de depuración(``CONFIG_DEBUG_INFO``).
> \ No newline at end of file

Re: [PATCH v2 1/3] docs: sp_SP: Add Spanish translation for Rust quick-start

[Carlos Bilbao]

On 3/4/26 12:07, Edwin Toribio wrote:
> Signed-off-by: Edwin Toribio <edwin.toribio.j@gmail.com>
> ---
>   .../translations/sp_SP/rust/quick-start.rst   | 384 ++++++++++++++++++
>   1 file changed, 384 insertions(+)
>   create mode 100644 Documentation/translations/sp_SP/rust/quick-start.rst
>
> diff --git a/Documentation/translations/sp_SP/rust/quick-start.rst b/Documentation/translations/sp_SP/rust/quick-start.rst
> new file mode 100644
> index 000000000..276b81971
> --- /dev/null
> +++ b/Documentation/translations/sp_SP/rust/quick-start.rst
> @@ -0,0 +1,384 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +.. include:: ../disclaimer-sp.rst
> +
> +:Original: Documentation/rust/quick-start.rst
> +:Translator: Edwin Toribio <edwin.toribio.j@gmail.com>
> +
> +.. _sp_rust_quick_start:
> +
> +Guía de inicio rápido
> +=====================
> +
> +Este documento describe cómo empezar con el desarrollo del kernel en Rust.
> +
> +Existen varias formas de instalar el conjunto de herramientas (toolchain) de Rust
> +necesario para el desarrollo del kernel. Una forma sencilla es utilizar los
> +paquetes de su distribución de Linux si son adecuados; la primera sección a
> +continuación explica este enfoque. Una ventaja de este método es que,
> +normalmente, la distribución hará coincidir el LLVM utilizado por Rust y Clang.
> +
> +Otra forma es utilizar las versiones estables precompiladas de LLVM+Rust
> +proporcionadas en `kernel.org <https://kernel.org/pub/tools/llvm/rust/>`_.
> +Estas son las mismas herramientas de LLVM ligeras y rápidas de
> +:ref:`Obtener LLVM <getting_llvm>` con versiones de Rust añadidas que son


BTW, I did get a warning here:

quick-start.rst:21: WARNING: undefined label: 'getting_llvm'


> +compatibles con Rust para Linux. Se proporcionan dos conjuntos: el "LLVM más
> +reciente" (latest LLVM) y el "LLVM coincidente" (matching LLVM) (consulte el
> +enlace para más información).
> +
> +Alternativamente, las dos secciones siguientes de "Requisitos" explican cada
> +componente y cómo instalarlos a través de ``rustup``, los instaladores
> +independientes de Rust y/o compilándolos.
> +
> +El resto del documento explica otros aspectos sobre cómo empezar.
> +
> +
> +Distribuciones
> +--------------
> +
> +Arch Linux
> +**********
> +
> +Arch Linux proporciona versiones recientes de Rust y, por lo tanto, debería
> +funcionar directamente, p. ej.::
> +
> +    pacman -S rust rust-src rust-bindgen
> +
> +
> +Debian
> +******
> +
> +Debian 13 (Trixie), así como Testing y Debian Unstable (Sid) proporcionan
> +versiones recientes de Rust y, por lo tanto, deberían funcionar directamente, p. ej.::
> +
> +    apt install rustc rust-src bindgen rustfmt rust-clippy
> +
> +
> +Fedora Linux
> +************
> +
> +Fedora Linux proporciona versiones recientes de Rust y, por lo tanto, debería
> +funcionar directamente, p. ej.::
> +
> +    dnf install rust rust-src bindgen-cli rustfmt clippy
> +
> +
> +Gentoo Linux
> +************
> +
> +Gentoo Linux (y especialmente la rama de pruebas) proporciona versiones
> +recientes de Rust y, por lo tanto, debería funcionar directamente, p. ej.::
> +
> +    USE='rust-src rustfmt clippy' emerge dev-lang/rust dev-util/bindgen
> +
> +Es posible que sea necesario configurar ``LIBCLANG_PATH``.
> +
> +
> +Nix
> +***
> +
> +Nix (canal unstable) proporciona versiones recientes de Rust y, por lo tanto,
> +debería funcionar directamente, p. ej.::
> +
> +    { pkgs ? import <nixpkgs> {} }:
> +    pkgs.mkShell {
> +      nativeBuildInputs = with pkgs; [ rustc rust-bindgen rustfmt clippy ];
> +      RUST_LIB_SRC = "${pkgs.rust.packages.stable.rustPlatform.rustLibSrc}";
> +    }
> +
> +
> +openSUSE
> +********
> +
> +openSUSE Slowroll y openSUSE Tumbleweed proporcionan versiones recientes de Rust
> +y, por lo tanto, deberían funcionar directamente, p. ej.::
> +
> +    zypper install rust rust1.79-src rust-bindgen clang
> +
> +
> +Ubuntu
> +******
> +
> +25.04
> +~~~~~
> +
> +Las versiones más recientes de Ubuntu proporcionan versiones recientes de Rust
> +y, por lo tanto, deberían funcionar directamente, p. ej.::
> +
> +    apt install rustc rust-src bindgen rustfmt rust-clippy
> +
> +Además, es necesario configurar ``RUST_LIB_SRC``, p. ej.::
> +
> +    RUST_LIB_SRC=/usr/src/rustc-$(rustc --version | cut -d' ' -f2)/library
> +
> +Para mayor comodidad, ``RUST_LIB_SRC`` puede exportarse al entorno global.
> +
> +
> +24.04 LTS y anteriores
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +Aunque Ubuntu 24.04 LTS y versiones anteriores todavía proporcionan versiones
> +recientes de Rust, requieren que se establezca alguna configuración adicional,
> +utilizando los paquetes con versión, p. ej.::
> +
> +    apt install rustc-1.80 rust-1.80-src bindgen-0.65 rustfmt-1.80 \
> +        rust-1.80-clippy
> +    ln -s /usr/lib/rust-1.80/bin/rustfmt /usr/bin/rustfmt-1.80
> +    ln -s /usr/lib/rust-1.80/bin/clippy-driver /usr/bin/clippy-driver-1.80
> +
> +Ninguno de estos paquetes establece sus herramientas como predeterminadas; por
> +lo tanto, deben especificarse explícitamente, p. ej.::
> +
> +    make LLVM=1 RUSTC=rustc-1.80 RUSTDOC=rustdoc-1.80 RUSTFMT=rustfmt-1.80 \
> +        CLIPPY_DRIVER=clippy-driver-1.80 BINDGEN=bindgen-0.65
> +
> +Alternativamente, modifique la variable ``PATH`` para colocar los binarios de
> +Rust 1.80 primero y establezca ``bindgen`` como predeterminado, p. ej.::
> +
> +    PATH=/usr/lib/rust-1.80/bin:$PATH
> +    update-alternatives --install /usr/bin/bindgen bindgen \
> +        /usr/bin/bindgen-0.65 100
> +    update-alternatives --set bindgen /usr/bin/bindgen-0.65
> +
> +``RUST_LIB_SRC`` debe configurarse cuando se usan los paquetes con versión, p. ej.::
> +
> +    RUST_LIB_SRC=/usr/src/rustc-$(rustc-1.80 --version | cut -d' ' -f2)/library
> +
> +Para mayor comodidad, ``RUST_LIB_SRC`` puede exportarse al entorno global.
> +
> +Además, ``bindgen-0.65`` está disponible en versiones más nuevas (24.04 LTS y
> +24.10), pero puede no estar disponible en las más antiguas (20.04 LTS y 22.04 LTS),
> +por lo que es posible que sea necesario compilar ``bindgen`` manualmente
> +(consulte más abajo).
> +
> +
> +Requisitos: Compilación
> +-----------------------
> +
> +Esta sección explica cómo obtener las herramientas necesarias para la compilación.
> +
> +Para comprobar fácilmente si se cumplen los requisitos, se puede utilizar el
> +siguiente objetivo (target)::
> +
> +    make LLVM=1 rustavailable
> +
> +Esto activa la misma lógica utilizada por Kconfig para determinar si debe
> +habilitarse ``RUST_IS_AVAILABLE``; pero también explica por qué no en caso
> +de que así sea.
> +
> +
> +rustc
> +*****
> +
> +Se requiere una versión reciente del compilador de Rust.
> +
> +Si se está utilizando ``rustup``, entre en el directorio de compilación del
> +kernel (o use el argumento ``--path=<build-dir>`` para el subcomando ``set``)
> +y ejecute, por ejemplo::
> +
> +    rustup override set stable
> +
> +Esto configurará su directorio de trabajo para usar la versión dada de
> +``rustc`` sin afectar a su conjunto de herramientas predeterminado.
> +
> +Tenga en cuenta que la anulación (override) se aplica al directorio de trabajo
> +actual (y sus subdirectorios).
> +
> +Si no está utilizando ``rustup``, obtenga un instalador independiente de:
> +
> +    https://forge.rust-lang.org/infra/other-installation-methods.html#standalone
> +
> +
> +Código fuente de la biblioteca estándar de Rust
> +***********************************************
> +
> +Se requiere el código fuente de la biblioteca estándar de Rust porque el sistema
> +de compilación compilará de forma cruzada ``core``.
> +
> +Si se está utilizando ``rustup``, ejecute::
> +
> +    rustup component add rust-src
> +
> +Los componentes se instalan por conjunto de herramientas, por lo que actualizar
> +la versión del compilador de Rust más adelante requiere volver a añadir el
> +componente.
> +
> +De lo contrario, si se utiliza un instalador independiente, el árbol de fuentes
> +de Rust puede descargarse en la carpeta de instalación del conjunto de
> +herramientas::
> +
> +    curl -L "https://static.rust-lang.org/dist/rust-src-$(rustc --version | cut -d' ' -f2).tar.gz" |
> +        tar -xzf - -C "$(rustc --print sysroot)/lib" \
> +        "rust-src-$(rustc --version | cut -d' ' -f2)/rust-src/lib/" \
> +        --strip-components=3
> +
> +En este caso, actualizar la versión del compilador de Rust más adelante requiere
> +actualizar manualmente el árbol de fuentes (esto se puede hacer eliminando
> +``$(rustc --print sysroot)/lib/rustlib/src/rust`` y volviendo a ejecutar el
> +comando anterior).
> +
> +
> +libclang
> +********
> +
> +``libclang`` (parte de LLVM) es utilizado por ``bindgen`` para entender el
> +código C en el kernel, lo que significa que LLVM debe estar instalado; al igual
> +que cuando el kernel se compila con ``LLVM=1``.
> +
> +Es probable que las distribuciones de Linux tengan una adecuada disponible, por
> +lo que es mejor comprobarlo primero.
> +
> +También hay algunos binarios para varios sistemas y arquitecturas subidos a:
> +
> +    https://releases.llvm.org/download.html
> +
> +De lo contrario, compilar LLVM lleva bastante tiempo, pero no es un proceso
> +complejo:
> +
> +    https://llvm.org/docs/GettingStarted.html#getting-the-source-code-and-building-llvm
> +
> +Consulte Documentation/kbuild/llvm.rst para obtener más información y otras
> +formas de obtener versiones precompiladas y paquetes de distribuciones.
> +
> +
> +bindgen
> +*******
> +
> +Los vínculos (bindings) con la parte de C del kernel se generan en tiempo de
> +compilación utilizando la herramienta ``bindgen``.
> +
> +Instálela, por ejemplo, mediante (tenga en cuenta que esto descargará y
> +compilará la herramienta desde el código fuente)::
> +
> +    cargo install --locked bindgen-cli
> +
> +``bindgen`` utiliza la caja (crate) ``clang-sys`` para encontrar un
> +``libclang`` adecuado (que puede estar vinculado estáticamente, dinámicamente
> +o cargado en tiempo de ejecución). Por defecto, el comando ``cargo`` anterior
> +producirá un binario ``bindgen`` que cargará ``libclang`` en tiempo de
> +ejecución. Si no se encuentra (o si se debe usar un ``libclang`` diferente al
> +encontrado), el proceso se puede ajustar, p. ej. utilizando la variable de entorno
> +``LIBCLANG_PATH``. Para más detalles, consulte la documentación de
> +``clang-sys`` en:
> +
> +    https://github.com/KyleMayes/clang-sys#linking
> +
> +    https://github.com/KyleMayes/clang-sys#environment-variables
> +
> +
> +Requisitos: Desarrollo
> +----------------------
> +
> +Esta sección explica cómo obtener las herramientas necesarias para el
> +desarrollo. Es decir, no son necesarias cuando solo se compila el kernel.
> +
> +
> +rustfmt
> +*******
> +
> +La herramienta ``rustfmt`` se utiliza para formatear automáticamente todo el
> +código Rust del kernel, incluyendo los vínculos de C generados (para más
> +detalles, consulte coding-guidelines.rst).
> +
> +Si se utiliza ``rustup``, su perfil ``default`` ya instala la herramienta, por
> +lo que no es necesario hacer nada. Si se utiliza otro perfil, el componente
> +puede instalarse manualmente::
> +
> +    rustup component add rustfmt
> +
> +Los instaladores independientes también vienen con ``rustfmt``.
> +
> +
> +clippy
> +******
> +
> +``clippy`` es un linter de Rust. Ejecutarlo proporciona advertencias
> +adicionales para el código Rust. Se puede ejecutar pasando ``CLIPPY=1`` a
> +``make`` (para más detalles, consulte general-information.rst).
> +
> +Si se utiliza ``rustup``, su perfil ``default`` ya instala la herramienta, por
> +lo que no es necesario hacer nada. Si se utiliza otro perfil, el componente
> +puede instalarse manualmente::
> +
> +    rustup component add clippy
> +
> +Los instaladores independientes también vienen con ``clippy``.
> +
> +
> +rustdoc
> +*******
> +
> +``rustdoc`` es la herramienta de documentación para Rust. Genera una atractiva
> +documentación en HTML para el código Rust (para más detalles, consulte
> +general-information.rst).
> +
> +``rustdoc`` también se utiliza para probar los ejemplos proporcionados en el
> +código Rust documentado (llamados doctests o pruebas de documentación). El
> +objetivo de Make ``rusttest`` utiliza esta función.
> +
> +Si se utiliza ``rustup``, todos los perfiles ya instalan la herramienta, por
> +lo que no es necesario hacer nada.
> +
> +Los instaladores independientes también vienen con ``rustdoc``.
> +
> +
> +rust-analyzer
> +*************
> +
> +El servidor de lenguaje `rust-analyzer <https://rust-analyzer.github.io/>`_
> +puede utilizarse con muchos editores para habilitar el resaltado de sintaxis,
> +el completado, el salto a la definición y otras funciones.
> +
> +``rust-analyzer`` necesita un archivo de configuración, ``rust-project.json``,
> +que puede generarse mediante el objetivo de Make ``rust-analyzer``::
> +
> +    make LLVM=1 rust-analyzer
> +
> +
> +Configuración
> +-------------
> +
> +El ``Rust support`` (``CONFIG_RUST``) debe habilitarse en el menú
> +``General setup``. La opción solo se muestra si se encuentra un conjunto de
> +herramientas de Rust adecuado (véase arriba), siempre que se cumplan los demás
> +requisitos. A su vez, esto hará visibles el resto de las opciones que
> +dependen de Rust.
> +
> +A continuación, vaya a::
> +
> +    Kernel hacking
> +        -> Sample kernel code
> +            -> Rust samples
> +
> +Y habilite algunos módulos de ejemplo, ya sea como integrados (built-in) o
> +como cargables.
> +
> +
> +Compilación
> +-----------
> +
> +Compilar un kernel con un conjunto de herramientas LLVM completo es la
> +configuración mejor soportada en este momento. Es decir::
> +
> +    make LLVM=1
> +
> +El uso de GCC también funciona para algunas configuraciones, pero es muy
> +experimental en este momento.
> +
> +
> +Hacking
> +-------
> +
> +Para profundizar más, eche un vistazo al código fuente de los ejemplos en
> +``samples/rust/``, al código de soporte de Rust bajo ``rust/`` y al menú
> +``Rust hacking`` bajo ``Kernel hacking``.
> +
> +Si se utiliza GDB/Binutils y los símbolos de Rust no se decodifican (demangle)
> +correctamente, la razón es que el conjunto de herramientas aún no soporta el
> +nuevo esquema de decoración de nombres (mangling) v0 de Rust. Hay algunas
> +soluciones:
> +
> +- Instalar una versión más reciente (GDB >= 10.2, Binutils >= 2.36).
> +
> +- Algunas versiones de GDB (p. ej. GDB 10.1 estándar) pueden utilizar los nombres
> +  pre-decodificados incrustados en la información de depuración(``CONFIG_DEBUG_INFO``).
> \ No newline at end of file

[PATCH v2 2/3] docs: sp_SP: Add Spanish translation for Rust general information

[Edwin Toribio]

Signed-off-by: Edwin Toribio <edwin.toribio.j@gmail.com>
---
 .../sp_SP/rust/general-information.rst        | 178 ++++++++++++++++++
 1 file changed, 178 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/rust/general-information.rst

diff --git a/Documentation/translations/sp_SP/rust/general-information.rst b/Documentation/translations/sp_SP/rust/general-information.rst
new file mode 100644
index 000000000..5b7b0225d
--- /dev/null
+++ b/Documentation/translations/sp_SP/rust/general-information.rst
@@ -0,0 +1,178 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-sp.rst
+
+:Original: Documentation/rust/general-information.rst
+:Translator: Edwin Toribio <edwin.toribio.j@gmail.com>
+
+.. _sp_rust_general_information:
+
+Información general
+===================
+
+Este documento contiene información útil que conviene conocer cuando se trabaja
+con el soporte de Rust en el kernel.
+
+
+``no_std``
+----------
+
+El soporte de Rust en el kernel solo puede vincularse a `core <https://doc.rust-lang.org/core/>`_,
+pero no a `std <https://doc.rust-lang.org/std/>`_. Las cajas (crates) destinadas
+al uso en el kernel deben optar por este comportamiento utilizando el atributo
+``#![no_std]``.
+
+
+.. _sp_rust_code_documentation:
+
+Documentación del código
+------------------------
+
+El código Rust del kernel se documenta mediante ``rustdoc``, su generador de
+documentación integrado.
+
+Los documentos HTML generados incluyen búsqueda integrada, elementos enlazados
+(p. ej. tipos, funciones, constantes), código fuente, etc. Pueden leerse en:
+
+    https://rust.docs.kernel.org
+
+Para linux-next, consulte:
+
+    https://rust.docs.kernel.org/next/
+
+También existen etiquetas para cada lanzamiento principal, p. ej.:
+
+    https://rust.docs.kernel.org/6.10/
+
+La documentación también puede generarse y leerse fácilmente de forma local.
+Esto es bastante rápido (del mismo orden que compilar el código en sí) y no se
+necesitan herramientas ni entornos especiales. Esto tiene la ventaja añadida de
+que estará adaptada a la configuración particular del kernel utilizada. Para
+generarla, utilice el objetivo ``rustdoc`` con la misma invocación utilizada
+para la compilación, p. ej.::
+
+    make LLVM=1 rustdoc
+
+Para leer la documentación localmente en su navegador web, ejecute por ejemplo::
+
+    xdg-open Documentation/output/rust/rustdoc/kernel/index.html
+
+Para aprender cómo escribir la documentación, consulte coding-guidelines.rst.
+
+
+Lints adicionales
+-----------------
+
+Aunque ``rustc`` es un compilador muy útil, existen algunos lints y análisis
+adicionales disponibles a través de ``clippy``, un linter de Rust. Para
+habilitarlo, pase ``CLIPPY=1`` a la misma invocación utilizada para la
+compilación, p. ej.::
+
+    make LLVM=1 CLIPPY=1
+
+Tenga en cuenta que Clippy puede cambiar la generación de código, por lo que no
+debe habilitarse mientras se compila un kernel de producción.
+
+
+Abstracciones vs. vínculos (bindings)
+-------------------------------------
+
+Las abstracciones son código Rust que envuelve la funcionalidad del kernel desde
+el lado de C.
+
+Para poder utilizar funciones y tipos del lado de C, se crean vínculos
+(bindings). Los vínculos son las declaraciones para Rust de esas funciones y
+tipos del lado de C.
+
+Por ejemplo, se podría escribir una abstracción ``Mutex`` en Rust que envuelva
+un ``struct mutex`` del lado de C y llame a sus funciones a través de los
+vínculos.
+
+Las abstracciones no están disponibles para todas las API internas y conceptos
+del kernel, pero se pretende que la cobertura se amplíe con el tiempo. Los
+módulos hoja ("Leaf") (p. ej. controladores/drivers) no deben utilizar los vínculos de C
+directamente. En su lugar, los subsistemas deben proporcionar abstracciones tan
+seguras como sea posible según sea necesario.
+
+.. code-block::
+
+                                                    rust/bindings/
+                                                   (rust/helpers/)
+
+                                                       include/ -----+ <-+
+                                                                     |   |
+      drivers/              rust/kernel/              +----------+ <-+   |
+        fs/                                           | bindgen  |       |
+       .../            +-------------------+          +----------+ --+   |
+                       |    Abstracciones  |                         |   |
+    +---------+        | +------+ +------+ |          +----------+   |   |
+    | mi_foo  | -----> | | foo  | | bar  | | -------> | Vínculos | <-+   |
+    | driver  | Segura | | sub- | | sub- | | Insegura |(Bindings)|       |
+    +---------+        | |sist. | |sist. | |          |          |       |
+         |             | +------+ +------+ |          |  caja    | <-----+
+         |             |   caja del kernel |          | bindings |       |
+         |             +-------------------+          +----------+       |
+         |                                                               |
+         +------------------# PROHIBIDO #--------------------------------+
+
+La idea principal es encapsular toda interacción directa con las API de C del
+kernel en abstracciones cuidadosamente revisadas y documentadas. Entonces, los
+usuarios de estas abstracciones no podrán introducir un comportamiento
+indefinido (UB) siempre que:
+
+#. Las abstracciones sean correctas ("sound").
+#. Cualquier bloque ``unsafe`` respete el contrato de seguridad necesario para
+   llamar a las operaciones dentro del bloque. Del mismo modo, cualquier
+   implementación ``unsafe impl`` respete el contrato de seguridad necesario
+   para implementar el rasgo (trait).
+
+Vínculos (Bindings)
+~~~~~~~~~~~~~~~~~~~
+
+Al incluir una cabecera C de ``include/`` en
+``rust/bindings/bindings_helper.h``, la herramienta ``bindgen`` generará
+automáticamente los vínculos para el subsistema incluido. Tras la compilación,
+vea los archivos de salida ``*_generated.rs`` en el directorio
+``rust/bindings/``.
+
+Para las partes de la cabecera C que ``bindgen`` no genera automáticamente, p. ej.
+funciones ``inline`` de C o macros no triviales, es aceptable añadir una pequeña
+función de envoltura (wrapper) en ``rust/helpers/`` para que esté disponible
+también para el lado de Rust.
+
+Abstracciones
+~~~~~~~~~~~~~
+
+Las abstracciones son la capa entre los vínculos y los usuarios dentro del
+kernel. Se encuentran en ``rust/kernel/`` y su función es encapsular el acceso
+inseguro (unsafe) a los vínculos en una API lo más segura posible que exponen a
+sus usuarios. Los usuarios de las abstracciones incluyen elementos como
+controladores o sistemas de archivos escritos en Rust.
+
+Además del aspecto de la seguridad, se supone que las abstracciones deben ser
+"ergonómicas", en el sentido de que convierten las interfaces de C en código
+Rust "idiomático". Ejemplos básicos son convertir la adquisición y liberación
+de recursos de C en constructores y destructores de Rust, o los códigos de error
+enteros de C en los tipos ``Result`` de Rust.
+
+
+Compilación condicional
+-----------------------
+
+El código Rust tiene acceso a la compilación condicional basada en la
+configuración del kernel:
+
+.. code-block:: rust
+
+    #[cfg(CONFIG_X)]       // Habilitado              (`y` o `m`)
+    #[cfg(CONFIG_X="y")]   // Habilitado como integrado (`y`)
+    #[cfg(CONFIG_X="m")]   // Habilitado como módulo    (`m`)
+    #[cfg(not(CONFIG_X))]  // Deshabilitado
+
+Para otros predicados que el ``cfg`` de Rust no soporta, p. ej. expresiones con
+comparaciones numéricas, se puede definir un nuevo símbolo Kconfig:
+
+.. code-block:: kconfig
+
+    config RUSTC_VERSION_MIN_107900
+        def_bool y if RUSTC_VERSION >= 107900
\ No newline at end of file
-- 
2.53.0

Re: [PATCH v2 2/3] docs: sp_SP: Add Spanish translation for Rust general information

[Carlos Bilbao]

On 3/4/26 12:07, Edwin Toribio wrote:

> Signed-off-by: Edwin Toribio <edwin.toribio.j@gmail.com>


  Signed-off-by: Carlos Bilbao <carlos.bilbao@kernel.org>


> ---
>   .../sp_SP/rust/general-information.rst        | 178 ++++++++++++++++++
>   1 file changed, 178 insertions(+)
>   create mode 100644 Documentation/translations/sp_SP/rust/general-information.rst
>
> diff --git a/Documentation/translations/sp_SP/rust/general-information.rst b/Documentation/translations/sp_SP/rust/general-information.rst
> new file mode 100644
> index 000000000..5b7b0225d
> --- /dev/null
> +++ b/Documentation/translations/sp_SP/rust/general-information.rst
> @@ -0,0 +1,178 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +.. include:: ../disclaimer-sp.rst
> +
> +:Original: Documentation/rust/general-information.rst
> +:Translator: Edwin Toribio <edwin.toribio.j@gmail.com>
> +
> +.. _sp_rust_general_information:
> +
> +Información general
> +===================
> +
> +Este documento contiene información útil que conviene conocer cuando se trabaja
> +con el soporte de Rust en el kernel.
> +
> +
> +``no_std``
> +----------
> +
> +El soporte de Rust en el kernel solo puede vincularse a `core <https://doc.rust-lang.org/core/>`_,
> +pero no a `std <https://doc.rust-lang.org/std/>`_. Las cajas (crates) destinadas
> +al uso en el kernel deben optar por este comportamiento utilizando el atributo
> +``#![no_std]``.
> +
> +
> +.. _sp_rust_code_documentation:
> +
> +Documentación del código
> +------------------------
> +
> +El código Rust del kernel se documenta mediante ``rustdoc``, su generador de
> +documentación integrado.
> +
> +Los documentos HTML generados incluyen búsqueda integrada, elementos enlazados
> +(p. ej. tipos, funciones, constantes), código fuente, etc. Pueden leerse en:
> +
> +    https://rust.docs.kernel.org
> +
> +Para linux-next, consulte:
> +
> +    https://rust.docs.kernel.org/next/
> +
> +También existen etiquetas para cada lanzamiento principal, p. ej.:
> +
> +    https://rust.docs.kernel.org/6.10/
> +
> +La documentación también puede generarse y leerse fácilmente de forma local.
> +Esto es bastante rápido (del mismo orden que compilar el código en sí) y no se
> +necesitan herramientas ni entornos especiales. Esto tiene la ventaja añadida de
> +que estará adaptada a la configuración particular del kernel utilizada. Para
> +generarla, utilice el objetivo ``rustdoc`` con la misma invocación utilizada
> +para la compilación, p. ej.::
> +
> +    make LLVM=1 rustdoc
> +
> +Para leer la documentación localmente en su navegador web, ejecute por ejemplo::
> +
> +    xdg-open Documentation/output/rust/rustdoc/kernel/index.html
> +
> +Para aprender cómo escribir la documentación, consulte coding-guidelines.rst.
> +
> +
> +Lints adicionales
> +-----------------
> +
> +Aunque ``rustc`` es un compilador muy útil, existen algunos lints y análisis
> +adicionales disponibles a través de ``clippy``, un linter de Rust. Para
> +habilitarlo, pase ``CLIPPY=1`` a la misma invocación utilizada para la
> +compilación, p. ej.::
> +
> +    make LLVM=1 CLIPPY=1
> +
> +Tenga en cuenta que Clippy puede cambiar la generación de código, por lo que no
> +debe habilitarse mientras se compila un kernel de producción.
> +
> +
> +Abstracciones vs. vínculos (bindings)
> +-------------------------------------
> +
> +Las abstracciones son código Rust que envuelve la funcionalidad del kernel desde
> +el lado de C.
> +
> +Para poder utilizar funciones y tipos del lado de C, se crean vínculos
> +(bindings). Los vínculos son las declaraciones para Rust de esas funciones y
> +tipos del lado de C.
> +
> +Por ejemplo, se podría escribir una abstracción ``Mutex`` en Rust que envuelva
> +un ``struct mutex`` del lado de C y llame a sus funciones a través de los
> +vínculos.
> +
> +Las abstracciones no están disponibles para todas las API internas y conceptos
> +del kernel, pero se pretende que la cobertura se amplíe con el tiempo. Los
> +módulos hoja ("Leaf") (p. ej. controladores/drivers) no deben utilizar los vínculos de C
> +directamente. En su lugar, los subsistemas deben proporcionar abstracciones tan
> +seguras como sea posible según sea necesario.
> +
> +.. code-block::
> +
> +                                                    rust/bindings/
> +                                                   (rust/helpers/)
> +
> +                                                       include/ -----+ <-+
> +                                                                     |   |
> +      drivers/              rust/kernel/              +----------+ <-+   |
> +        fs/                                           | bindgen  |       |
> +       .../            +-------------------+          +----------+ --+   |
> +                       |    Abstracciones  |                         |   |
> +    +---------+        | +------+ +------+ |          +----------+   |   |
> +    | mi_foo  | -----> | | foo  | | bar  | | -------> | Vínculos | <-+   |
> +    | driver  | Segura | | sub- | | sub- | | Insegura |(Bindings)|       |
> +    +---------+        | |sist. | |sist. | |          |          |       |
> +         |             | +------+ +------+ |          |  caja    | <-----+
> +         |             |   caja del kernel |          | bindings |       |
> +         |             +-------------------+          +----------+       |
> +         |                                                               |
> +         +------------------# PROHIBIDO #--------------------------------+
> +
> +La idea principal es encapsular toda interacción directa con las API de C del
> +kernel en abstracciones cuidadosamente revisadas y documentadas. Entonces, los
> +usuarios de estas abstracciones no podrán introducir un comportamiento
> +indefinido (UB) siempre que:
> +
> +#. Las abstracciones sean correctas ("sound").
> +#. Cualquier bloque ``unsafe`` respete el contrato de seguridad necesario para
> +   llamar a las operaciones dentro del bloque. Del mismo modo, cualquier
> +   implementación ``unsafe impl`` respete el contrato de seguridad necesario
> +   para implementar el rasgo (trait).
> +
> +Vínculos (Bindings)
> +~~~~~~~~~~~~~~~~~~~
> +
> +Al incluir una cabecera C de ``include/`` en
> +``rust/bindings/bindings_helper.h``, la herramienta ``bindgen`` generará
> +automáticamente los vínculos para el subsistema incluido. Tras la compilación,
> +vea los archivos de salida ``*_generated.rs`` en el directorio
> +``rust/bindings/``.
> +
> +Para las partes de la cabecera C que ``bindgen`` no genera automáticamente, p. ej.
> +funciones ``inline`` de C o macros no triviales, es aceptable añadir una pequeña
> +función de envoltura (wrapper) en ``rust/helpers/`` para que esté disponible
> +también para el lado de Rust.
> +
> +Abstracciones
> +~~~~~~~~~~~~~
> +
> +Las abstracciones son la capa entre los vínculos y los usuarios dentro del
> +kernel. Se encuentran en ``rust/kernel/`` y su función es encapsular el acceso
> +inseguro (unsafe) a los vínculos en una API lo más segura posible que exponen a
> +sus usuarios. Los usuarios de las abstracciones incluyen elementos como
> +controladores o sistemas de archivos escritos en Rust.
> +
> +Además del aspecto de la seguridad, se supone que las abstracciones deben ser
> +"ergonómicas", en el sentido de que convierten las interfaces de C en código
> +Rust "idiomático". Ejemplos básicos son convertir la adquisición y liberación
> +de recursos de C en constructores y destructores de Rust, o los códigos de error
> +enteros de C en los tipos ``Result`` de Rust.
> +
> +
> +Compilación condicional
> +-----------------------
> +
> +El código Rust tiene acceso a la compilación condicional basada en la
> +configuración del kernel:
> +
> +.. code-block:: rust
> +
> +    #[cfg(CONFIG_X)]       // Habilitado              (`y` o `m`)
> +    #[cfg(CONFIG_X="y")]   // Habilitado como integrado (`y`)
> +    #[cfg(CONFIG_X="m")]   // Habilitado como módulo    (`m`)
> +    #[cfg(not(CONFIG_X))]  // Deshabilitado
> +
> +Para otros predicados que el ``cfg`` de Rust no soporta, p. ej. expresiones con
> +comparaciones numéricas, se puede definir un nuevo símbolo Kconfig:
> +
> +.. code-block:: kconfig
> +
> +    config RUSTC_VERSION_MIN_107900
> +        def_bool y if RUSTC_VERSION >= 107900
> \ No newline at end of file

[PATCH v2 3/3] docs: sp_SP: Add Spanish translation for Rust coding guidelines

[Edwin Toribio]

Signed-off-by: Edwin Toribio <edwin.toribio.j@gmail.com>
---
 .../sp_SP/rust/coding-guidelines.rst          | 543 ++++++++++++++++++
 .../translations/sp_SP/rust/index.rst         |  45 ++
 2 files changed, 588 insertions(+)
 create mode 100644 Documentation/translations/sp_SP/rust/coding-guidelines.rst
 create mode 100644 Documentation/translations/sp_SP/rust/index.rst

diff --git a/Documentation/translations/sp_SP/rust/coding-guidelines.rst b/Documentation/translations/sp_SP/rust/coding-guidelines.rst
new file mode 100644
index 000000000..084925d3d
--- /dev/null
+++ b/Documentation/translations/sp_SP/rust/coding-guidelines.rst
@@ -0,0 +1,543 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-sp.rst
+
+:Original: Documentation/rust/coding-guidelines.rst
+:Translator: Edwin Toribio <edwin.toribio.j@gmail.com>
+
+.. _sp_rust_coding_guidelines:
+
+===============================
+Pautas de codificación de Rust
+===============================
+
+Este documento describe cómo escribir código Rust en el kernel.
+
+Estilo y formato
+----------------
+
+El código debe formatearse utilizando ``rustfmt``. De esta manera, una persona
+que contribuya de vez en cuando al kernel no necesita aprender y recordar una
+guía de estilo adicional. Más importante aún, los revisores y mantenedores
+ya no necesitan dedicar tiempo a señalar problemas de estilo y, por lo tanto,
+es posible que se necesiten menos rondas de parches para aplicar un cambio.
+
+.. note:: Las convenciones sobre comentarios y documentación no son verificadas por
+  ``rustfmt``. Por lo tanto, todavía es necesario encargarse de ellas.
+
+Se utilizan los ajustes predeterminados de ``rustfmt``. Esto significa que se sigue
+el estilo idiomático de Rust. Por ejemplo, se utilizan 4 espacios para la
+sangría en lugar de tabulaciones.
+
+Es conveniente configurar los editores/IDE para que formateen al escribir, al
+guardar o al momento de realizar el commit. Sin embargo, si por alguna
+razón es necesario reformatear todas las fuentes de Rust del kernel en algún
+momento, se puede ejecutar lo siguiente::
+
+	make LLVM=1 rustfmt
+
+También es posible comprobar si todo está formateado (imprimiendo un diff en
+caso contrario), p. ej., para una CI (Integración Continua), con::
+
+	make LLVM=1 rustfmtcheck
+
+Al igual que ``clang-format`` para el resto del kernel, ``rustfmt`` funciona en
+archivos individuales y no requiere una configuración del kernel. A veces,
+incluso puede funcionar con código que contenga errores.
+
+Importaciones
+~~~~~~~~~~~~~
+
+``rustfmt``, por defecto, formatea las importaciones de una manera propensa a
+conflictos durante las fusiones (*merges*) y reajustes (*rebases*), ya que en algunos
+casos condensa varios elementos en la misma línea. Por ejemplo:
+
+.. code-block:: rust
+
+	// No use este estilo.
+	use crate::{
+	    example1,
+	    example2::{example3, example4, example5},
+	    example6, example7,
+	    example8::example9,
+	};
+
+En su lugar, el kernel utiliza un diseño vertical que se ve así:
+
+.. code-block:: rust
+
+	use crate::{
+	    example1,
+	    example2::{
+	        example3,
+	        example4,
+	        example5, //
+	    },
+	    example6,
+	    example7,
+	    example8::example9, //
+	};
+
+Es decir, cada elemento va en su propia línea, y se utilizan llaves tan pronto como
+haya más de un elemento en una lista. 
+
+El comentario vacío al final permite preservar este formato. No solo eso, ``rustfmt`` 
+reformateará de hecho las importaciones verticalmente cuando se añade el comentario vacío.
+Importaciones
+~~~~~~~~~~~~~
+
+``rustfmt``, por defecto, formatea las importaciones de una manera propensa a
+conflictos durante las fusiones (*merges*) y reajustes (*rebases*), ya que en algunos
+casos condensa varios elementos en la misma línea. Por ejemplo:
+
+.. code-block:: rust
+
+	// No use este estilo.
+	use crate::{
+	    example1,
+	    example2::{example3, example4, example5},
+	    example6, example7,
+	    example8::example9,
+	};
+
+En su lugar, el kernel utiliza un diseño vertical que se ve así:
+
+.. code-block:: rust
+
+	use crate::{
+	    example1,
+	    example2::{
+	        example3,
+	        example4,
+	        example5, //
+	    },
+	    example6,
+	    example7,
+	    example8::example9, //
+	};
+
+Es decir, cada elemento va en su propia línea, y se utilizan llaves tan pronto como
+haya más de un elemento en una lista.
+
+El comentario vacío al final permite preservar este formato. No solo eso,
+``rustfmt`` reformateará de hecho las importaciones verticalmente cuando se añade el
+comentario vacío. Es decir, es posible reformatear fácilmente el ejemplo original
+al estilo esperado ejecutando ``rustfmt`` sobre una entrada como:
+
+.. code-block:: rust
+
+    // No use este estilo.
+    use crate::{
+        example1,
+        example2::{example3, example4, example5, //
+        },
+        example6, example7,
+        example8::example9, //
+    };
+
+El comentario vacío al final funciona para importaciones anidadas, como se muestra
+arriba, así como para importaciones de un solo elemento; esto puede ser útil para
+minimizar los diffs dentro de las series de parches:
+
+.. code-block:: rust
+
+    use crate::{
+        example1, //
+    };
+
+El comentario vacío al final funciona en cualquiera de las líneas dentro de las
+llaves, pero se prefiere mantenerlo en el último elemento, ya que recuerda a la
+coma final en otros formateadores. A veces puede ser más sencillo evitar mover el
+comentario varias veces dentro de una serie de parches debido a cambios en la lista.
+
+Puede haber casos en los que sea necesario hacer excepciones, p. ej., nada de esto es
+una regla estricta. También hay código que aún no ha sido migrado a este estilo, pero
+por favor, no introduzca código en otros estilos.
+
+Eventualmente, el objetivo es conseguir que ``rustfmt`` soporte este estilo de
+formateo (o uno similar) automáticamente en una versión estable sin requerir el
+comentario vacío al final. Por lo tanto, en algún momento, el objetivo es eliminar
+esos comentarios.
+
+
+Comentarios
+-----------
+
+Los comentarios "normales" (p. ej., ``//``, en lugar de la documentación del
+código que comienza con ``///`` o ``//!``) se escriben en Markdown de la misma
+manera que los comentarios de documentación, aunque no se renderizarán. Esto
+mejora la consistencia, simplifica las reglas y permite mover contenido entre
+los dos tipos de comentarios más fácilmente. Por ejemplo:
+
+.. code-block:: rust
+
+    // `object` está listo para ser manejado ahora.
+    f(object);
+
+Además, al igual que la documentación, los comentarios comienzan con mayúscula
+al principio de una oración y terminan con un punto (aunque sea una sola
+oración). Esto incluye ``// SAFETY:``, ``// TODO:`` y otros comentarios
+"etiquetados", p. ej.:
+
+.. code-block:: rust
+
+    // FIXME: El error debe manejarse adecuadamente.
+
+Los comentarios no deben utilizarse con fines de documentación: los comentarios
+están destinados a los detalles de implementación, no a los usuarios. Esta
+distinción es útil incluso si el lector del archivo fuente es tanto un
+implementador como un usuario de una API. De hecho, a veces es útil usar tanto
+comentarios como documentación al mismo tiempo. Por ejemplo, para una lista
+``TODO`` o para comentar sobre la documentación misma. En este último caso,
+los comentarios pueden insertarse en el medio; es decir, más cerca de la línea
+de documentación que se desea comentar. Para cualquier otro caso, los
+comentarios se escriben después de la documentación, p. ej.:
+
+.. code-block:: rust
+
+    /// Devuelve un nuevo [`Foo`].
+    ///
+    /// # Ejemplos
+    ///
+    // TODO: Encontrar un mejor ejemplo.
+    /// ```
+    /// let foo = f(42);
+    /// ```
+    // FIXME: Usar un enfoque falible(basado en errores).
+    pub fn f(x: i32) -> Foo {
+        // ...
+    }
+
+Esto se aplica tanto a elementos públicos como privados. Esto aumenta la
+consistencia con los elementos públicos, permite cambios de visibilidad con
+menos cambios involucrados y nos permitirá generar potencialmente la
+documentación también para elementos privados. En otras palabras, si se escribe
+documentación para un elemento privado, se debe seguir utilizando ``///``.
+Por ejemplo:
+
+.. code-block:: rust
+
+    /// Mi función privada.
+    // TODO: ...
+    fn f() {}
+
+Un tipo especial de comentarios son los comentarios ``// SAFETY:``. Estos deben
+aparecer antes de cada bloque ``unsafe``, y explican por qué el código dentro
+del bloque es correcto/seguro, es decir, por qué no puede activar un
+comportamiento indefinido en ningún caso, p. ej.:
+
+.. code-block:: rust
+
+    // SAFETY: `p` es válido según los requisitos de seguridad.
+    unsafe { *p = 0; }
+
+Los comentarios ``// SAFETY:`` no deben confundirse con las secciones
+``# Safety`` en la documentación del código. Las secciones ``# Safety``
+especifican el contrato de quienes invocan (para funciones) o los
+implementadores (para traits) deben cumplir. Los comentarios ``// SAFETY:``
+muestran por qué una llamada (para funciones) o una implementación (para
+traits) realmente respeta las condiciones previas establecidas en una sección
+``# Safety`` o en la referencia del lenguaje.
+
+Documentación del código
+------------------------
+
+El código de Rust del kernel no se documenta como el código de C del kernel (p. ej.,
+a través de kernel-doc). En su lugar, se utiliza el sistema habitual para
+documentar código Rust: la herramienta ``rustdoc``, que utiliza Markdown (un
+lenguaje de marcado ligero).
+
+Para aprender Markdown, hay muchas guías disponibles. Por ejemplo, la que se
+encuentra en:
+
+    https://commonmark.org/help/
+
+Así es como podría verse una función de Rust bien documentada:
+
+.. code-block:: rust
+
+    /// Devuelve el valor [`Some`] contenido, consumiendo el valor `self`,
+    /// sin comprobar que el valor no sea [`None`].
+    ///
+    /// # Safety
+    ///
+    /// Invocar este método en [`None`] es *[comportamiento indefinido]*.
+    ///
+    /// [comportamiento indefinido]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html
+    ///
+    /// # Ejemplos
+    ///
+    /// ```
+    /// let x = Some("aire");
+    /// assert_eq!(unsafe { x.unwrap_unchecked() }, "aire");
+    /// ```
+    pub unsafe fn unwrap_unchecked(self) -> T {
+        match self {
+            Some(val) => val,
+
+            // SAFETY: El contrato de seguridad debe ser respetado por quien invoca.
+            None => unsafe { hint::unreachable_unchecked() },
+        }
+    }
+
+Este ejemplo muestra algunas características de ``rustdoc`` y algunas convenciones
+seguidas en el kernel:
+
+- El primer párrafo debe ser una sola oración que describa brevemente lo que
+  hace el elemento documentado. Las explicaciones adicionales deben ir en
+  párrafos extra.
+
+- Las funciones inseguras (``unsafe``) deben documentar sus condiciones previas
+  de seguridad bajo una sección ``# Safety``.
+
+- Aunque no se muestra aquí, si una función puede entrar en pánico (``panic``),
+  las condiciones bajo las cuales esto sucede deben describirse bajo una
+  sección ``# Panics``.
+
+  Por favor, tenga en cuenta que entrar en pánico debe ser muy raro y usarse
+  solo con una buena razón. En casi todos los casos, se debe usar un enfoque
+  basado en errores, devolviendo típicamente un ``Result``.
+
+- Si proporcionar ejemplos de uso ayudara a los lectores, estos deben escribirse
+  en una sección llamada ``# Ejemplos``.
+
+- Los elementos de Rust (funciones, tipos, constantes...) deben estar vinculados
+  apropiadamente (``rustdoc`` creará un enlace automáticamente).
+
+- Cualquier bloque ``unsafe`` debe estar precedido por un comentario ``// SAFETY:``
+  que describa por qué el código interior es seguro.
+
+  Aunque a veces la razón pueda parecer trivial y, por lo tanto, innecesaria,
+  escribir estos comentarios no es solo una buena manera de documentar lo que
+  se ha tenido en cuenta, sino que, lo más importante, proporciona una forma de
+  saber que no existen restricciones implícitas *adicionales*.
+
+Para obtener más información sobre cómo escribir documentación para Rust y
+características adicionales, consulte el libro de ``rustdoc`` en:
+
+    https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html
+
+Además, el kernel admite la creación de enlaces relativos al árbol de fuentes
+anteponiendo al destino del enlace ``srctree/``. Por ejemplo:
+
+.. code-block:: rust
+
+    //! Cabecera C: [`include/linux/printk.h`](srctree/include/linux/printk.h)
+
+o:
+
+.. code-block:: rust
+
+    /// [`struct mutex`]: srctree/include/linux/mutex.h
+
+
+Tipos FFI de C
+--------------
+
+El código de Rust del kernel se refiere a los tipos de C, como ``int``, utilizando
+alias de tipos como ``c_int``, que están disponibles en el preludio de ``kernel``.
+Por favor, no use los alias de ``core::ffi``; es posible que no se mapeen a los
+tipos correctos.
+
+Por lo general, se debe hacer referencia a estos alias directamente por su
+identificador; es decir, como una ruta de un solo segmento. Por ejemplo:
+
+.. code-block:: rust
+
+    fn f(p: *const c_char) -> c_int {
+        // ...
+    }
+
+Nomenclatura
+------------
+
+El código de Rust del kernel sigue las convenciones habituales de nomenclatura de Rust:
+
+    https://rust-lang.github.io/api-guidelines/naming.html
+
+Cuando los conceptos de C existentes (p. ej., macros, funciones, objetos...) se
+envuelven en una abstracción de Rust, se debe utilizar un nombre lo más cercano
+posible al lado de C para evitar confusiones y mejorar la legibilidad al cambiar
+entre los lados de C y Rust. Por ejemplo, las macros como ``pr_info``
+de C se nombran igual en el lado de Rust.
+
+Dicho esto, el uso de mayúsculas y minúsculas (*casing*) debe ajustarse para seguir
+las convenciones de nomenclatura de Rust, y el espacio de nombres (*namespacing*)
+introducido por módulos y tipos no debe repetirse en los nombres de los elementos.
+Por ejemplo, al envolver constantes como:
+
+.. code-block:: c
+
+    #define GPIO_LINE_DIRECTION_IN  0
+    #define GPIO_LINE_DIRECTION_OUT 1
+
+El equivalente en Rust podría verse así (ignorando la documentación):
+
+.. code-block:: rust
+
+    pub mod gpio {
+        pub enum LineDirection {
+            In = bindings::GPIO_LINE_DIRECTION_IN as _,
+            Out = bindings::GPIO_LINE_DIRECTION_OUT as _,
+        }
+    }
+
+Es decir, el equivalente de ``GPIO_LINE_DIRECTION_IN`` se referenciaría como
+``gpio::LineDirection::In``. En particular, no debería nombrarse
+``gpio::gpio_line_direction::GPIO_LINE_DIRECTION_IN``.
+
+Lints
+-----
+
+En Rust, es posible permitir (``allow``) advertencias particulares (diagnósticos,
+lints) localmente, haciendo que el compilador ignore las instancias de una
+advertencia determinada dentro de una función, módulo o bloque específico, etc.
+
+Es similar a ``#pragma GCC diagnostic push`` + ``ignored`` + ``pop`` en C
+[#]_:
+
+.. code-block:: c
+
+    #pragma GCC diagnostic push
+    #pragma GCC diagnostic ignored "-Wunused-function"
+    static void f(void) {}
+    #pragma GCC diagnostic pop
+
+.. [#] En este caso particular, pueden utilizarse los atributos
+       ``__{always,maybe}_unused`` del kernel (el ``[[maybe_unused]]`` de C23);
+       sin embargo, el ejemplo pretende reflejar el lint equivalente en Rust
+       que se analiza a continuación.
+
+Pero es mucho menos prolijo(``verbose``):
+
+.. code-block:: rust
+
+    #[allow(dead_code)]
+    fn f() {}
+
+Gracias a esa virtud, es posible habilitar cómodamente más diagnósticos por
+defecto (es decir, fuera de los niveles ``W=``). En particular, aquellos que
+pueden tener algunos falsos positivos pero que, de otro modo, son bastante útiles
+de mantener habilitados para detectar posibles errores.
+
+Además de eso, Rust proporciona el atributo ``expect``, que lleva esto más allá.
+Hace que el compilador advierta si la advertencia no se produjo. Por ejemplo, lo
+siguiente asegurará que, cuando se llame a ``f()`` en algún lugar, tengamos que
+eliminar el atributo:
+
+.. code-block:: rust
+
+    #[expect(dead_code)]
+    fn f() {}
+
+Si no lo hacemos, recibimos una advertencia del compilador::
+
+    warning: this lint expectation is unfulfilled
+     --> x.rs:3:10
+      |
+    3 | #[expect(dead_code)]
+      |          ^^^^^^^^^
+      |
+      = note: `#[warn(unfulfilled_lint_expectations)]` on by default
+
+Esto significa que los ``expect`` no se olvidan cuando ya no son necesarios, lo
+que puede ocurrir en varias situaciones, p. ej.:
+
+- Atributos temporales añadidos durante el desarrollo.
+
+- Mejoras en los lints del compilador, Clippy o herramientas personalizadas que
+  pueden eliminar un falso positivo.
+
+- Cuando el lint ya no es necesario porque se esperaba que fuera eliminado en
+  algún momento, como el ejemplo de ``dead_code`` anterior.
+
+También aumenta la visibilidad de los ``allow`` restantes y reduce la posibilidad
+de aplicar uno incorrectamente.
+
+Por lo tanto, prefiera ``expect`` sobre ``allow`` a menos que:
+
+- La compilación condicional active la advertencia en algunos casos pero no en
+  otros.
+
+  Si solo hay unos pocos casos en los que se activa la advertencia (o no se
+  activa) en comparación con el número total de casos, entonces se puede
+  considerar el uso de un ``expect`` condicional (es decir,
+  ``cfg_attr(..., expect(...))``). De lo contrario, es probable que sea más
+  sencillo usar simplemente ``allow``.
+
+- Dentro de macros, cuando las diferentes invocaciones pueden crear código
+  expandido que activa la advertencia en algunos casos pero no en otros.
+
+- Cuando el código puede activar una advertencia para algunas arquitecturas
+  pero no para otras, como un moldeado (*cast*) ``as`` a un tipo FFI de C.
+
+Como ejemplo más desarrollado, considere por ejemplo este programa:
+
+.. code-block:: rust
+
+    fn g() {}
+
+    fn main() {
+        #[cfg(CONFIG_X)]
+        g();
+    }
+
+Aquí, la función ``g()`` es código muerto (*dead code*) si ``CONFIG_X`` no está
+establecido. ¿Podemos usar ``expect`` aquí?
+
+.. code-block:: rust
+
+    #[expect(dead_code)]
+    fn g() {}
+
+    fn main() {
+        #[cfg(CONFIG_X)]
+        g();
+    }
+
+Esto emitiría un lint si ``CONFIG_X`` está establecido, ya que no es código muerto
+en esa configuración. Por lo tanto, en casos como este, no podemos usar ``expect``
+tal cual.
+
+Una posibilidad simple es usar ``allow``:
+
+.. code-block:: rust
+
+    #[allow(dead_code)]
+    fn g() {}
+
+    fn main() {
+        #[cfg(CONFIG_X)]
+        g();
+    }
+
+Una alternativa sería usar un ``expect`` condicional:
+
+.. code-block:: rust
+
+    #[cfg_attr(not(CONFIG_X), expect(dead_code))]
+    fn g() {}
+
+    fn main() {
+        #[cfg(CONFIG_X)]
+        g();
+    }
+
+Esto aseguraría que, si alguien introduce otra llamada a ``g()`` en algún lugar
+(p. ej., de forma incondicional), entonces se detectaría que ya no es código muerto.
+Sin embargo, el ``cfg_attr`` es más complejo que un simple ``allow``.
+
+Por lo tanto, es probable que no valga la pena usar ``expect`` condicionales cuando
+están involucradas más de una o dos configuraciones o cuando el lint puede
+activarse debido a cambios no locales (como ``dead_code``).
+
+Para obtener más información sobre diagnósticos en Rust, consulte:
+
+    https://doc.rust-lang.org/stable/reference/attributes/diagnostics.html
+
+Manejo de errores
+-----------------
+
+Para obtener información de referencia y pautas sobre el manejo de errores
+específicos de Rust para Linux, consulte:
+
+    https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust
\ No newline at end of file
diff --git a/Documentation/translations/sp_SP/rust/index.rst b/Documentation/translations/sp_SP/rust/index.rst
new file mode 100644
index 000000000..ff1db4487
--- /dev/null
+++ b/Documentation/translations/sp_SP/rust/index.rst
@@ -0,0 +1,45 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-sp.rst
+
+:Original: Documentation/rust/quick-start.rst
+:Translator: Edwin Toribio <edwin.toribio.j@gmail.com>
+
+.. _sp_rust_index:
+
+Rust
+====
+
+Documentación relacionada con Rust dentro del kernel. Para empezar a usar Rust
+en el kernel, por favor lea la guía quick-start.rst.
+
+Documentación del código
+------------------------
+
+Dada una configuración del kernel, el kernel puede generar documentación del
+código Rust, p. ej., HTML renderizado por la herramienta ``rustdoc``.
+
+.. only:: rustdoc and html
+
+    Esta documentación del kernel fue construida con la `documentación del código Rust
+    <rustdoc/kernel/index.html>`_.
+
+.. only:: not rustdoc and html
+
+    Esta documentación del kernel no fue construida con la documentación del código Rust.
+
+Se proporciona una versión pregenerada en:
+
+    https://rust.docs.kernel.org
+
+Por favor, consulte la sección :ref:`Documentación del código <rust_code_documentation>`
+para más detalles.
+
+.. toctree::
+    :maxdepth: 1
+
+    quick-start
+    general-information
+    coding-guidelines
+
+También puede encontrar materiales de aprendizaje para Rust en su sección en
+:doc:`../process/kernel-docs`.
\ No newline at end of file
-- 
2.53.0

Re: [PATCH v2 3/3] docs: sp_SP: Add Spanish translation for Rust coding guidelines

[Carlos Bilbao]

On 3/4/26 12:07, Edwin Toribio wrote:

> Signed-off-by: Edwin Toribio <edwin.toribio.j@gmail.com>
> ---
>   .../sp_SP/rust/coding-guidelines.rst          | 543 ++++++++++++++++++
>   .../translations/sp_SP/rust/index.rst         |  45 ++


This is a big problem: in Documentation/translations/sp_SP/index.rst, the
new directory rust/index hasn't been added to the toctree. If you don't
include this, the new Rust pages won't show up in the HTML build. I’d
strongly recommend always testing with make htmldocs and checking the
result in your local browser before sending patches to Documentation/
(you'd have noticed this issue).


>   2 files changed, 588 insertions(+)
>   create mode 100644 Documentation/translations/sp_SP/rust/coding-guidelines.rst
>   create mode 100644 Documentation/translations/sp_SP/rust/index.rst
>
> diff --git a/Documentation/translations/sp_SP/rust/coding-guidelines.rst b/Documentation/translations/sp_SP/rust/coding-guidelines.rst
> new file mode 100644
> index 000000000..084925d3d
> --- /dev/null
> +++ b/Documentation/translations/sp_SP/rust/coding-guidelines.rst
> @@ -0,0 +1,543 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. include:: ../disclaimer-sp.rst
> +
> +:Original: Documentation/rust/coding-guidelines.rst


The original doc is Documentation/rust/index.rst


> +:Translator: Edwin Toribio <edwin.toribio.j@gmail.com>
> +
> +.. _sp_rust_coding_guidelines:
> +
> +===============================
> +Pautas de codificación de Rust
> +===============================
> +
> +Este documento describe cómo escribir código Rust en el kernel.
> +
> +Estilo y formato
> +----------------
> +
> +El código debe formatearse utilizando ``rustfmt``. De esta manera, una persona
> +que contribuya de vez en cuando al kernel no necesita aprender y recordar una
> +guía de estilo adicional. Más importante aún, los revisores y mantenedores
> +ya no necesitan dedicar tiempo a señalar problemas de estilo y, por lo tanto,
> +es posible que se necesiten menos rondas de parches para aplicar un cambio.
> +
> +.. note:: Las convenciones sobre comentarios y documentación no son verificadas por
> +  ``rustfmt``. Por lo tanto, todavía es necesario encargarse de ellas.
> +
> +Se utilizan los ajustes predeterminados de ``rustfmt``. Esto significa que se sigue
> +el estilo idiomático de Rust. Por ejemplo, se utilizan 4 espacios para la
> +sangría en lugar de tabulaciones.
> +
> +Es conveniente configurar los editores/IDE para que formateen al escribir, al
> +guardar o al momento de realizar el commit. Sin embargo, si por alguna
> +razón es necesario reformatear todas las fuentes de Rust del kernel en algún
> +momento, se puede ejecutar lo siguiente::
> +
> +	make LLVM=1 rustfmt
> +
> +También es posible comprobar si todo está formateado (imprimiendo un diff en
> +caso contrario), p. ej., para una CI (Integración Continua), con::
> +
> +	make LLVM=1 rustfmtcheck
> +
> +Al igual que ``clang-format`` para el resto del kernel, ``rustfmt`` funciona en
> +archivos individuales y no requiere una configuración del kernel. A veces,
> +incluso puede funcionar con código que contenga errores.
> +
> +Importaciones
> +~~~~~~~~~~~~~
> +
> +``rustfmt``, por defecto, formatea las importaciones de una manera propensa a
> +conflictos durante las fusiones (*merges*) y reajustes (*rebases*), ya que en algunos
> +casos condensa varios elementos en la misma línea. Por ejemplo:
> +
> +.. code-block:: rust
> +
> +	// No use este estilo.
> +	use crate::{
> +	    example1,
> +	    example2::{example3, example4, example5},
> +	    example6, example7,
> +	    example8::example9,
> +	};
> +
> +En su lugar, el kernel utiliza un diseño vertical que se ve así:
> +
> +.. code-block:: rust
> +
> +	use crate::{
> +	    example1,
> +	    example2::{
> +	        example3,
> +	        example4,
> +	        example5, //
> +	    },
> +	    example6,
> +	    example7,
> +	    example8::example9, //
> +	};
> +
> +Es decir, cada elemento va en su propia línea, y se utilizan llaves tan pronto como
> +haya más de un elemento en una lista.
> +
> +El comentario vacío al final permite preservar este formato. No solo eso, ``rustfmt``
> +reformateará de hecho las importaciones verticalmente cuando se añade el comentario vacío.
> +Importaciones


Importaciones section is here twice, be more careful!


> +~~~~~~~~~~~~~
> +
> +``rustfmt``, por defecto, formatea las importaciones de una manera propensa a
> +conflictos durante las fusiones (*merges*) y reajustes (*rebases*), ya que en algunos
> +casos condensa varios elementos en la misma línea. Por ejemplo:
> +
> +.. code-block:: rust
> +
> +	// No use este estilo.
> +	use crate::{
> +	    example1,
> +	    example2::{example3, example4, example5},
> +	    example6, example7,
> +	    example8::example9,
> +	};
> +
> +En su lugar, el kernel utiliza un diseño vertical que se ve así:
> +
> +.. code-block:: rust
> +
> +	use crate::{
> +	    example1,
> +	    example2::{
> +	        example3,
> +	        example4,
> +	        example5, //
> +	    },
> +	    example6,
> +	    example7,
> +	    example8::example9, //
> +	};
> +
> +Es decir, cada elemento va en su propia línea, y se utilizan llaves tan pronto como
> +haya más de un elemento en una lista.
> +
> +El comentario vacío al final permite preservar este formato. No solo eso,
> +``rustfmt`` reformateará de hecho las importaciones verticalmente cuando se añade el
> +comentario vacío. Es decir, es posible reformatear fácilmente el ejemplo original
> +al estilo esperado ejecutando ``rustfmt`` sobre una entrada como:
> +
> +.. code-block:: rust
> +
> +    // No use este estilo.
> +    use crate::{
> +        example1,
> +        example2::{example3, example4, example5, //
> +        },
> +        example6, example7,
> +        example8::example9, //
> +    };
> +
> +El comentario vacío al final funciona para importaciones anidadas, como se muestra
> +arriba, así como para importaciones de un solo elemento; esto puede ser útil para
> +minimizar los diffs dentro de las series de parches:
> +
> +.. code-block:: rust
> +
> +    use crate::{
> +        example1, //
> +    };
> +
> +El comentario vacío al final funciona en cualquiera de las líneas dentro de las
> +llaves, pero se prefiere mantenerlo en el último elemento, ya que recuerda a la
> +coma final en otros formateadores. A veces puede ser más sencillo evitar mover el
> +comentario varias veces dentro de una serie de parches debido a cambios en la lista.
> +
> +Puede haber casos en los que sea necesario hacer excepciones, p. ej., nada de esto es
> +una regla estricta. También hay código que aún no ha sido migrado a este estilo, pero
> +por favor, no introduzca código en otros estilos.
> +
> +Eventualmente, el objetivo es conseguir que ``rustfmt`` soporte este estilo de
> +formateo (o uno similar) automáticamente en una versión estable sin requerir el
> +comentario vacío al final. Por lo tanto, en algún momento, el objetivo es eliminar
> +esos comentarios.
> +
> +
> +Comentarios
> +-----------
> +
> +Los comentarios "normales" (p. ej., ``//``, en lugar de la documentación del
> +código que comienza con ``///`` o ``//!``) se escriben en Markdown de la misma
> +manera que los comentarios de documentación, aunque no se renderizarán. Esto
> +mejora la consistencia, simplifica las reglas y permite mover contenido entre
> +los dos tipos de comentarios más fácilmente. Por ejemplo:
> +
> +.. code-block:: rust
> +
> +    // `object` está listo para ser manejado ahora.
> +    f(object);
> +
> +Además, al igual que la documentación, los comentarios comienzan con mayúscula
> +al principio de una oración y terminan con un punto (aunque sea una sola
> +oración). Esto incluye ``// SAFETY:``, ``// TODO:`` y otros comentarios
> +"etiquetados", p. ej.:
> +
> +.. code-block:: rust
> +
> +    // FIXME: El error debe manejarse adecuadamente.
> +
> +Los comentarios no deben utilizarse con fines de documentación: los comentarios
> +están destinados a los detalles de implementación, no a los usuarios. Esta
> +distinción es útil incluso si el lector del archivo fuente es tanto un
> +implementador como un usuario de una API. De hecho, a veces es útil usar tanto
> +comentarios como documentación al mismo tiempo. Por ejemplo, para una lista
> +``TODO`` o para comentar sobre la documentación misma. En este último caso,
> +los comentarios pueden insertarse en el medio; es decir, más cerca de la línea
> +de documentación que se desea comentar. Para cualquier otro caso, los
> +comentarios se escriben después de la documentación, p. ej.:
> +
> +.. code-block:: rust
> +
> +    /// Devuelve un nuevo [`Foo`].
> +    ///
> +    /// # Ejemplos
> +    ///
> +    // TODO: Encontrar un mejor ejemplo.
> +    /// ```
> +    /// let foo = f(42);
> +    /// ```
> +    // FIXME: Usar un enfoque falible(basado en errores).
> +    pub fn f(x: i32) -> Foo {
> +        // ...
> +    }
> +
> +Esto se aplica tanto a elementos públicos como privados. Esto aumenta la
> +consistencia con los elementos públicos, permite cambios de visibilidad con
> +menos cambios involucrados y nos permitirá generar potencialmente la
> +documentación también para elementos privados. En otras palabras, si se escribe
> +documentación para un elemento privado, se debe seguir utilizando ``///``.
> +Por ejemplo:
> +
> +.. code-block:: rust
> +
> +    /// Mi función privada.
> +    // TODO: ...
> +    fn f() {}
> +
> +Un tipo especial de comentarios son los comentarios ``// SAFETY:``. Estos deben
> +aparecer antes de cada bloque ``unsafe``, y explican por qué el código dentro
> +del bloque es correcto/seguro, es decir, por qué no puede activar un
> +comportamiento indefinido en ningún caso, p. ej.:
> +
> +.. code-block:: rust
> +
> +    // SAFETY: `p` es válido según los requisitos de seguridad.
> +    unsafe { *p = 0; }
> +
> +Los comentarios ``// SAFETY:`` no deben confundirse con las secciones
> +``# Safety`` en la documentación del código. Las secciones ``# Safety``
> +especifican el contrato de quienes invocan (para funciones) o los
> +implementadores (para traits) deben cumplir. Los comentarios ``// SAFETY:``
> +muestran por qué una llamada (para funciones) o una implementación (para
> +traits) realmente respeta las condiciones previas establecidas en una sección
> +``# Safety`` o en la referencia del lenguaje.
> +
> +Documentación del código
> +------------------------
> +
> +El código de Rust del kernel no se documenta como el código de C del kernel (p. ej.,
> +a través de kernel-doc). En su lugar, se utiliza el sistema habitual para
> +documentar código Rust: la herramienta ``rustdoc``, que utiliza Markdown (un
> +lenguaje de marcado ligero).
> +
> +Para aprender Markdown, hay muchas guías disponibles. Por ejemplo, la que se
> +encuentra en:
> +
> +    https://commonmark.org/help/
> +
> +Así es como podría verse una función de Rust bien documentada:
> +
> +.. code-block:: rust
> +
> +    /// Devuelve el valor [`Some`] contenido, consumiendo el valor `self`,
> +    /// sin comprobar que el valor no sea [`None`].
> +    ///
> +    /// # Safety
> +    ///
> +    /// Invocar este método en [`None`] es *[comportamiento indefinido]*.
> +    ///
> +    /// [comportamiento indefinido]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html
> +    ///
> +    /// # Ejemplos


In Rust, there's some keywords like # Examples, # Safety, # Panics, etc,
that need to stay in English.


> +    ///
> +    /// ```
> +    /// let x = Some("aire");
> +    /// assert_eq!(unsafe { x.unwrap_unchecked() }, "aire");
> +    /// ```
> +    pub unsafe fn unwrap_unchecked(self) -> T {
> +        match self {
> +            Some(val) => val,
> +
> +            // SAFETY: El contrato de seguridad debe ser respetado por quien invoca.
> +            None => unsafe { hint::unreachable_unchecked() },
> +        }
> +    }
> +
> +Este ejemplo muestra algunas características de ``rustdoc`` y algunas convenciones
> +seguidas en el kernel:
> +
> +- El primer párrafo debe ser una sola oración que describa brevemente lo que
> +  hace el elemento documentado. Las explicaciones adicionales deben ir en
> +  párrafos extra.
> +
> +- Las funciones inseguras (``unsafe``) deben documentar sus condiciones previas
> +  de seguridad bajo una sección ``# Safety``.
> +
> +- Aunque no se muestra aquí, si una función puede entrar en pánico (``panic``),
> +  las condiciones bajo las cuales esto sucede deben describirse bajo una
> +  sección ``# Panics``.
> +
> +  Por favor, tenga en cuenta que entrar en pánico debe ser muy raro y usarse
> +  solo con una buena razón. En casi todos los casos, se debe usar un enfoque
> +  basado en errores, devolviendo típicamente un ``Result``.
> +
> +- Si proporcionar ejemplos de uso ayudara a los lectores, estos deben escribirse
> +  en una sección llamada ``# Ejemplos``.
> +
> +- Los elementos de Rust (funciones, tipos, constantes...) deben estar vinculados
> +  apropiadamente (``rustdoc`` creará un enlace automáticamente).
> +
> +- Cualquier bloque ``unsafe`` debe estar precedido por un comentario ``// SAFETY:``
> +  que describa por qué el código interior es seguro.
> +
> +  Aunque a veces la razón pueda parecer trivial y, por lo tanto, innecesaria,
> +  escribir estos comentarios no es solo una buena manera de documentar lo que
> +  se ha tenido en cuenta, sino que, lo más importante, proporciona una forma de
> +  saber que no existen restricciones implícitas *adicionales*.
> +
> +Para obtener más información sobre cómo escribir documentación para Rust y
> +características adicionales, consulte el libro de ``rustdoc`` en:
> +
> +    https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html
> +
> +Además, el kernel admite la creación de enlaces relativos al árbol de fuentes
> +anteponiendo al destino del enlace ``srctree/``. Por ejemplo:
> +
> +.. code-block:: rust
> +
> +    //! Cabecera C: [`include/linux/printk.h`](srctree/include/linux/printk.h)
> +
> +o:
> +
> +.. code-block:: rust
> +
> +    /// [`struct mutex`]: srctree/include/linux/mutex.h
> +
> +
> +Tipos FFI de C
> +--------------
> +
> +El código de Rust del kernel se refiere a los tipos de C, como ``int``, utilizando
> +alias de tipos como ``c_int``, que están disponibles en el preludio de ``kernel``.
> +Por favor, no use los alias de ``core::ffi``; es posible que no se mapeen a los
> +tipos correctos.
> +
> +Por lo general, se debe hacer referencia a estos alias directamente por su
> +identificador; es decir, como una ruta de un solo segmento. Por ejemplo:
> +
> +.. code-block:: rust
> +
> +    fn f(p: *const c_char) -> c_int {
> +        // ...
> +    }
> +
> +Nomenclatura
> +------------
> +
> +El código de Rust del kernel sigue las convenciones habituales de nomenclatura de Rust:
> +
> +    https://rust-lang.github.io/api-guidelines/naming.html
> +
> +Cuando los conceptos de C existentes (p. ej., macros, funciones, objetos...) se
> +envuelven en una abstracción de Rust, se debe utilizar un nombre lo más cercano
> +posible al lado de C para evitar confusiones y mejorar la legibilidad al cambiar
> +entre los lados de C y Rust. Por ejemplo, las macros como ``pr_info``
> +de C se nombran igual en el lado de Rust.
> +
> +Dicho esto, el uso de mayúsculas y minúsculas (*casing*) debe ajustarse para seguir
> +las convenciones de nomenclatura de Rust, y el espacio de nombres (*namespacing*)
> +introducido por módulos y tipos no debe repetirse en los nombres de los elementos.
> +Por ejemplo, al envolver constantes como:
> +
> +.. code-block:: c
> +
> +    #define GPIO_LINE_DIRECTION_IN  0
> +    #define GPIO_LINE_DIRECTION_OUT 1
> +
> +El equivalente en Rust podría verse así (ignorando la documentación):
> +
> +.. code-block:: rust
> +
> +    pub mod gpio {
> +        pub enum LineDirection {
> +            In = bindings::GPIO_LINE_DIRECTION_IN as _,
> +            Out = bindings::GPIO_LINE_DIRECTION_OUT as _,
> +        }
> +    }
> +
> +Es decir, el equivalente de ``GPIO_LINE_DIRECTION_IN`` se referenciaría como
> +``gpio::LineDirection::In``. En particular, no debería nombrarse
> +``gpio::gpio_line_direction::GPIO_LINE_DIRECTION_IN``.
> +
> +Lints
> +-----
> +
> +En Rust, es posible permitir (``allow``) advertencias particulares (diagnósticos,
> +lints) localmente, haciendo que el compilador ignore las instancias de una
> +advertencia determinada dentro de una función, módulo o bloque específico, etc.
> +
> +Es similar a ``#pragma GCC diagnostic push`` + ``ignored`` + ``pop`` en C
> +[#]_:
> +
> +.. code-block:: c
> +
> +    #pragma GCC diagnostic push
> +    #pragma GCC diagnostic ignored "-Wunused-function"
> +    static void f(void) {}
> +    #pragma GCC diagnostic pop
> +
> +.. [#] En este caso particular, pueden utilizarse los atributos
> +       ``__{always,maybe}_unused`` del kernel (el ``[[maybe_unused]]`` de C23);
> +       sin embargo, el ejemplo pretende reflejar el lint equivalente en Rust
> +       que se analiza a continuación.
> +
> +Pero es mucho menos prolijo(``verbose``):
> +
> +.. code-block:: rust
> +
> +    #[allow(dead_code)]
> +    fn f() {}
> +
> +Gracias a esa virtud, es posible habilitar cómodamente más diagnósticos por
> +defecto (es decir, fuera de los niveles ``W=``). En particular, aquellos que
> +pueden tener algunos falsos positivos pero que, de otro modo, son bastante útiles
> +de mantener habilitados para detectar posibles errores.
> +
> +Además de eso, Rust proporciona el atributo ``expect``, que lleva esto más allá.
> +Hace que el compilador advierta si la advertencia no se produjo. Por ejemplo, lo
> +siguiente asegurará que, cuando se llame a ``f()`` en algún lugar, tengamos que
> +eliminar el atributo:
> +
> +.. code-block:: rust
> +
> +    #[expect(dead_code)]
> +    fn f() {}
> +
> +Si no lo hacemos, recibimos una advertencia del compilador::
> +
> +    warning: this lint expectation is unfulfilled
> +     --> x.rs:3:10
> +      |
> +    3 | #[expect(dead_code)]
> +      |          ^^^^^^^^^
> +      |
> +      = note: `#[warn(unfulfilled_lint_expectations)]` on by default
> +
> +Esto significa que los ``expect`` no se olvidan cuando ya no son necesarios, lo
> +que puede ocurrir en varias situaciones, p. ej.:
> +
> +- Atributos temporales añadidos durante el desarrollo.
> +
> +- Mejoras en los lints del compilador, Clippy o herramientas personalizadas que
> +  pueden eliminar un falso positivo.
> +
> +- Cuando el lint ya no es necesario porque se esperaba que fuera eliminado en
> +  algún momento, como el ejemplo de ``dead_code`` anterior.
> +
> +También aumenta la visibilidad de los ``allow`` restantes y reduce la posibilidad
> +de aplicar uno incorrectamente.
> +
> +Por lo tanto, prefiera ``expect`` sobre ``allow`` a menos que:
> +
> +- La compilación condicional active la advertencia en algunos casos pero no en
> +  otros.
> +
> +  Si solo hay unos pocos casos en los que se activa la advertencia (o no se
> +  activa) en comparación con el número total de casos, entonces se puede
> +  considerar el uso de un ``expect`` condicional (es decir,
> +  ``cfg_attr(..., expect(...))``). De lo contrario, es probable que sea más
> +  sencillo usar simplemente ``allow``.
> +
> +- Dentro de macros, cuando las diferentes invocaciones pueden crear código
> +  expandido que activa la advertencia en algunos casos pero no en otros.
> +
> +- Cuando el código puede activar una advertencia para algunas arquitecturas
> +  pero no para otras, como un moldeado (*cast*) ``as`` a un tipo FFI de C.
> +
> +Como ejemplo más desarrollado, considere por ejemplo este programa:
> +
> +.. code-block:: rust
> +
> +    fn g() {}
> +
> +    fn main() {
> +        #[cfg(CONFIG_X)]
> +        g();
> +    }
> +
> +Aquí, la función ``g()`` es código muerto (*dead code*) si ``CONFIG_X`` no está
> +establecido. ¿Podemos usar ``expect`` aquí?
> +
> +.. code-block:: rust
> +
> +    #[expect(dead_code)]
> +    fn g() {}
> +
> +    fn main() {
> +        #[cfg(CONFIG_X)]
> +        g();
> +    }
> +
> +Esto emitiría un lint si ``CONFIG_X`` está establecido, ya que no es código muerto
> +en esa configuración. Por lo tanto, en casos como este, no podemos usar ``expect``
> +tal cual.
> +
> +Una posibilidad simple es usar ``allow``:
> +
> +.. code-block:: rust
> +
> +    #[allow(dead_code)]
> +    fn g() {}
> +
> +    fn main() {
> +        #[cfg(CONFIG_X)]
> +        g();
> +    }
> +
> +Una alternativa sería usar un ``expect`` condicional:
> +
> +.. code-block:: rust
> +
> +    #[cfg_attr(not(CONFIG_X), expect(dead_code))]
> +    fn g() {}
> +
> +    fn main() {
> +        #[cfg(CONFIG_X)]
> +        g();
> +    }
> +
> +Esto aseguraría que, si alguien introduce otra llamada a ``g()`` en algún lugar
> +(p. ej., de forma incondicional), entonces se detectaría que ya no es código muerto.
> +Sin embargo, el ``cfg_attr`` es más complejo que un simple ``allow``.
> +
> +Por lo tanto, es probable que no valga la pena usar ``expect`` condicionales cuando
> +están involucradas más de una o dos configuraciones o cuando el lint puede
> +activarse debido a cambios no locales (como ``dead_code``).
> +
> +Para obtener más información sobre diagnósticos en Rust, consulte:
> +
> +    https://doc.rust-lang.org/stable/reference/attributes/diagnostics.html
> +
> +Manejo de errores
> +-----------------
> +
> +Para obtener información de referencia y pautas sobre el manejo de errores
> +específicos de Rust para Linux, consulte:
> +
> +    https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust
> \ No newline at end of file
> diff --git a/Documentation/translations/sp_SP/rust/index.rst b/Documentation/translations/sp_SP/rust/index.rst
> new file mode 100644
> index 000000000..ff1db4487
> --- /dev/null
> +++ b/Documentation/translations/sp_SP/rust/index.rst
> @@ -0,0 +1,45 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. include:: ../disclaimer-sp.rst
> +
> +:Original: Documentation/rust/quick-start.rst
> +:Translator: Edwin Toribio <edwin.toribio.j@gmail.com>
> +
> +.. _sp_rust_index:
> +
> +Rust
> +====
> +
> +Documentación relacionada con Rust dentro del kernel. Para empezar a usar Rust
> +en el kernel, por favor lea la guía quick-start.rst.
> +
> +Documentación del código
> +------------------------
> +
> +Dada una configuración del kernel, el kernel puede generar documentación del
> +código Rust, p. ej., HTML renderizado por la herramienta ``rustdoc``.
> +
> +.. only:: rustdoc and html
> +
> +    Esta documentación del kernel fue construida con la `documentación del código Rust
> +    <rustdoc/kernel/index.html>`_.
> +
> +.. only:: not rustdoc and html
> +
> +    Esta documentación del kernel no fue construida con la documentación del código Rust.
> +
> +Se proporciona una versión pregenerada en:
> +
> +    https://rust.docs.kernel.org
> +
> +Por favor, consulte la sección :ref:`Documentación del código <rust_code_documentation>`
> +para más detalles.
> +
> +.. toctree::
> +    :maxdepth: 1
> +
> +    quick-start
> +    general-information
> +    coding-guidelines
> +
> +También puede encontrar materiales de aprendizaje para Rust en su sección en
> +:doc:`../process/kernel-docs`.
> \ No newline at end of file


Un saludo y gracias!

Carlos

Re: [PATCH v2 3/3] docs: sp_SP: Add Spanish translation for Rust coding guidelines

[Miguel Ojeda]

On Sun, Mar 8, 2026 at 7:40 PM Carlos Bilbao
<carlos.bilbao.osdev@gmail.com> wrote:
>
> In Rust, there's some keywords like # Examples, # Safety, # Panics, etc,
> that need to stay in English.

I don't know what the translations' policy is, but shouldn't all code
remain in English? i.e. not just section names, but comments and Rust
docs (i.e. `///`, `//!` and `//`).

From a quick look, at least I see another couple translations that
keeps them in English.

Thanks!

Cheers,
Miguel

Re: [PATCH v2 3/3] docs: sp_SP: Add Spanish translation for Rust coding guidelines

[Carlos Bilbao]

Hello Miguel,

On 3/8/26 12:16, Miguel Ojeda wrote:
> On Sun, Mar 8, 2026 at 7:40 PM Carlos Bilbao
> <carlos.bilbao.osdev@gmail.com> wrote:
>> In Rust, there's some keywords like # Examples, # Safety, # Panics, etc,
>> that need to stay in English.
> I don't know what the translations' policy is, but shouldn't all code
> remain in English? i.e. not just section names, but comments and Rust
> docs (i.e. `///`, `//!` and `//`).
>
>  From a quick look, at least I see another couple translations that
> keeps them in English.


TBH, a reasonable case can be made either way, and there are no written
rules on this question AFAIK.

In terms of precedent, the Chinese (simplified) translation keeps code
blocks unchanged, which I suppose avoids giving the impression that
non-English comments are acceptable in kernel code.

That said, the goal of translation docs is accessibility, and since these
are illustrative snippets, Spanish comments help readers follow the example
without having to switch back to English. Personally, that argument
convinces me more.

>
> Thanks!
>
> Cheers,
> Miguel


Thanks,

Carlos

Re: [PATCH v2 3/3] docs: sp_SP: Add Spanish translation for Rust coding guidelines

[Miguel Ojeda]

On Tue, Mar 10, 2026 at 4:33 AM Carlos Bilbao
<carlos.bilbao.osdev@gmail.com> wrote:
>
> TBH, a reasonable case can be made either way, and there are no written
> rules on this question AFAIK.
>
> In terms of precedent, the Chinese (simplified) translation keeps code
> blocks unchanged, which I suppose avoids giving the impression that
> non-English comments are acceptable in kernel code.
>
> That said, the goal of translation docs is accessibility, and since these
> are illustrative snippets, Spanish comments help readers follow the example
> without having to switch back to English. Personally, that argument
> convinces me more.

Yeah, I guess it depends for whom the docs are meant, e.g. whether the
reader is one that will afterwards go and read code or the English
side of the docs, or whether it is meant as docs that external readers
may want to read to inform themselves about what the kernel.

I don't know if there is a policy for translations about this, but if
it doesn't exist, then it may be a good opportunity to align.

(Relatedly, machine translation on technical topics is quite good
nowadays, so if the intention is that a reader may read the English
docs or the code afterwards, perhaps it could be nice to have a
suggested way for them to read those docs via machine translation,
especially if there are accessible/free/OSS/... solutions).

I hope that helps!

Cheers,
Miguel

Re: [PATCH v2 3/3] docs: sp_SP: Add Spanish translation for Rust coding guidelines

[Carlos Bilbao]

Hello,

On 3/10/26 13:14, Miguel Ojeda wrote:
> On Tue, Mar 10, 2026 at 4:33 AM Carlos Bilbao
> <carlos.bilbao.osdev@gmail.com> wrote:
>> TBH, a reasonable case can be made either way, and there are no written
>> rules on this question AFAIK.
>>
>> In terms of precedent, the Chinese (simplified) translation keeps code
>> blocks unchanged, which I suppose avoids giving the impression that
>> non-English comments are acceptable in kernel code.
>>
>> That said, the goal of translation docs is accessibility, and since these
>> are illustrative snippets, Spanish comments help readers follow the example
>> without having to switch back to English. Personally, that argument
>> convinces me more.
> Yeah, I guess it depends for whom the docs are meant, e.g. whether the
> reader is one that will afterwards go and read code or the English
> side of the docs, or whether it is meant as docs that external readers
> may want to read to inform themselves about what the kernel.
>
> I don't know if there is a policy for translations about this, but if
> it doesn't exist, then it may be a good opportunity to align.


I'll leave it up to you, Edwin, just make sure to leave keywords in
English.


>
> (Relatedly, machine translation on technical topics is quite good
> nowadays, so if the intention is that a reader may read the English
> docs or the code afterwards, perhaps it could be nice to have a
> suggested way for them to read those docs via machine translation,
> especially if there are accessible/free/OSS/... solutions).


Yes, I suppose one day I’ll work up the courage to use automatic
translations for what’s left. But I’d still need to review everything
carefully to catch mistranslations (the classic Spanish example is “driver”
to “conductor”), though in practice the issues are often subtler. It also
means resisting the temptation to skim large paragraphs and trust the
tools; something that’s probably more tempting with docs than with code.


>
> I hope that helps!
>
> Cheers,
> Miguel


Thanks,

Carlos

Re: [PATCH v2 3/3] docs: sp_SP: Add Spanish translation for Rust coding guidelines

[Miguel Ojeda]

On Wed, Mar 11, 2026 at 12:57 AM Carlos Bilbao
<carlos.bilbao.osdev@gmail.com> wrote:
>
> Yes, I suppose one day I’ll work up the courage to use automatic
> translations for what’s left. But I’d still need to review everything
> carefully to catch mistranslations (the classic Spanish example is “driver”
> to “conductor”), though in practice the issues are often subtler. It also
> means resisting the temptation to skim large paragraphs and trust the
> tools; something that’s probably more tempting with docs than with code.

Ah, I didn't mean to commit change, i.e. not for maintainers. Rather,
I meant a set of suggestions for readers about how to best read the
English side of the docs.

That is, when they are done with the parts that are actually
translated and humanly reviewed, they might need to keep going and
read some English parts (or the code itself), and thus perhaps they
may appreciate suggestions on how that may be best accomplished could
help.

And for those nowadays using AI for translation, perhaps what could be
added is a set of guidelines to guide the AI while translating (e.g.
to have a greater chance of not failing on the subtle points you
mention), both for all translations (like whether to translate
examples) and for particular languages separately (like the "driver"
example, though I imagine that is handled by context nowadays quite
well).

Anyway, like the policy across all translations for whether translate
the code snippets, these are also just random ideas that came to mind;
and perhaps they have been suggested before. :)

I hope it helps, and thanks!

Cheers,
Miguel

Re: [PATCH v2 3/3] docs: sp_SP: Add Spanish translation for Rust coding guidelines

[Carlos Bilbao]

Hello,

On 3/10/26 23:11, Miguel Ojeda wrote:
> On Wed, Mar 11, 2026 at 12:57 AM Carlos Bilbao
> <carlos.bilbao.osdev@gmail.com> wrote:
>> Yes, I suppose one day I’ll work up the courage to use automatic
>> translations for what’s left. But I’d still need to review everything
>> carefully to catch mistranslations (the classic Spanish example is “driver”
>> to “conductor”), though in practice the issues are often subtler. It also
>> means resisting the temptation to skim large paragraphs and trust the
>> tools; something that’s probably more tempting with docs than with code.
> Ah, I didn't mean to commit change, i.e. not for maintainers. Rather,
> I meant a set of suggestions for readers about how to best read the
> English side of the docs.
>
> That is, when they are done with the parts that are actually
> translated and humanly reviewed, they might need to keep going and
> read some English parts (or the code itself), and thus perhaps they
> may appreciate suggestions on how that may be best accomplished could
> help.
>
> And for those nowadays using AI for translation, perhaps what could be
> added is a set of guidelines to guide the AI while translating (e.g.
> to have a greater chance of not failing on the subtle points you
> mention), both for all translations (like whether to translate
> examples) and for particular languages separately (like the "driver"
> example, though I imagine that is handled by context nowadays quite
> well).


Ah, I understand now. Yes, maybe a prepared prompt with some
well-thought-out guidance would help; that’s a good point.


>
> Anyway, like the policy across all translations for whether translate
> the code snippets, these are also just random ideas that came to mind;
> and perhaps they have been suggested before. :)
>
> I hope it helps, and thanks!
>
> Cheers,
> Miguel


Regards,

Carlos

Re: [PATCH v2 0/3] docs: sp_SP: Add Rust documentation section

[Carlos Bilbao]

Hello Edwin,

On 3/4/26 12:07, Edwin Toribio wrote:
> This series provides the Spanish translation for the Rust documentation
> section in the Linux kernel, including the quick-start guide, general
> information, and coding guidelines.
>
> In this second version, all documents have been unified and updated to
> comply with the feedback provided regarding style and technical accuracy.
>
> Changes in v2:
> - Added new translations: coding-guidelines.rst and index.rst.
> - Standardized the use of "p. ej." abbreviation throughout all files.
> - Fixed the Hacking section truncation in quick-start.rst.
>
> Edwin Toribio (3):
>    docs: sp_SP: Add Spanish translation for Rust quick-start
>    docs: sp_SP: Add Spanish translation for Rust general information
>    docs: sp_SP: Add Spanish translation for Rust coding guidelines
>
>   .../sp_SP/rust/coding-guidelines.rst          | 543 ++++++++++++++++++
>   .../sp_SP/rust/general-information.rst        | 178 ++++++
>   .../translations/sp_SP/rust/index.rst         |  45 ++
>   .../translations/sp_SP/rust/quick-start.rst   | 384 +++++++++++++
>   4 files changed, 1150 insertions(+)
>   create mode 100644 Documentation/translations/sp_SP/rust/coding-guidelines.rst
>   create mode 100644 Documentation/translations/sp_SP/rust/general-information.rst
>   create mode 100644 Documentation/translations/sp_SP/rust/index.rst
>   create mode 100644 Documentation/translations/sp_SP/rust/quick-start.rst

Thanks, Edwin, this is much better! We're close, but not quite there yet.
We'll need a v3 for a couple of reasons.

Thanks,

Carlos