code:
NOTE:
This is a version of Documentation/process/stable-api-nonsense.rst translated
into korean
This document is maintained by Minchan Kim <minchan@kernel.org>
If you find any difference between this document and the original file or
a problem with the translation, please contact the maintainer of this file.

Please also note that the purpose of this file is to be easier to
read for non English (read: korean) speakers and is not intended as
a fork. So if you have any comments or updates for this file please
try to update the original English file first.

==================================
이 문서는
Documentation/process/stable-api-nonsense.rst
의 한글 번역입니다.

역자： 김민찬 <minchan@kernel.org>
감수： 이제이미 <jamee.lee@samsung.com>
==================================

리눅스 커널 드라이버 인터페이스
(여러분들의 모든 질문에 대한 답 그리고 다른 몇가지)

Greg Kroah-Hartman <greg@kroah.com>

이 문서는 리눅스가 왜 바이너리 커널 인터페이스를 갖지 않는지, 왜 변하지
않는(stable) 커널 인터페이스를 갖지 않는지를 설명하기 위해 쓰여졌다.
이 문서는 커널과 유저공간 사이의 인터페이스가 아니라 커널 내부의
인터페이스들을 설명하고 있다는 것을 유념하라. 커널과 유저공간 사이의
인터페이스는 응용프로그램이 사용하는 syscall 인터페이스이다. 그 인터페이스는
오랫동안 거의 변하지 않았고 앞으로도 변하지 않을 것이다. 나는 pre 0.9에서
만들어졌지만 최신의 2.6 커널 배포에서도 잘 동작하는 프로그램을 가지고
있다. 이 인터페이스는 사용자와 응용프로그램 개발자들이 변하지 않을 것이라고
여길수 있는 것이다.

초록
----
여러분은 변하지 않는 커널 인터페이스를 원한다고 생각하지만 실제로는
그렇지 않으며 심지어는 그것을 알아채지 못한다. 여러분이 원하는 것은
안정되게 실행되는 드라이버이며 드라이버가 메인 커널 트리에 있을 때
그런 안정적인 드라이버를 얻을 수 있게 된다. 또한 여러분의 드라이버가
메인 커널 트리에 있다면 다른 많은 좋은 이점들을 얻게 된다. 그러한 것들이
리눅스를 강건하고, 안정적이며, 성숙한 운영체제로 만들어 놓음으로써
여러분들로 하여금 바로 리눅스를 사용하게 만드는 이유이다.

소개
----

커널 내부의 인터페이스가 바뀌는 것을 걱정하며 커널 드라이버를 작성하고
싶어하는 사람은 정말 이상한 사람이다. 세상의 대다수의 사람들은 이 인터페이스를
보지못할 것이며 전혀 걱정하지도 않는다.

먼저, 나는 closed 소스, hidden 소스, binary blobs, 소스 wrappers, 또는 GPL로
배포되었지만 소스 코드를 갖고 있지 않은 커널 드라이버들을 설명하는 어떤 다른
용어들에 관한 어떤 법적인 문제에 관해서는 언급하지 않을 것이다. 어떤 법적인
질문들을 가지고 있다면 변호사와 연락하라. 나는 프로그래머이므로 여기서 기술적인
문제들만을 설명하려고 한다. (법적인 문제를 경시하는 것은 아니다. 그런 문제들은
엄연히 현실에 있고 여러분들은 항상 그 문제들을 인식하고 있을 필요는 있다.)

자, 두가지의 주요 주제가 있다. 바이너리 커널 인터페이스들과 변하지 않는
커널 소스 인터페이들. 그것들은 서로 의존성을 가지고 있지만 바이너리
문제를 먼저 풀고 넘어갈 것이다.

바이너리 커널 인터페이스
------------------------
우리가 변하지 않는 커널 소스 인터페이스를 가지고 있다고 가정하자. 그러면
바이너리 인터페이스 또한 자연적으로 변하지 않을까? 틀렸다. 리눅스 커널에
관한 다음 사실들을 생각해보라.
   - 여러분들이 사용하는 C 컴파일러의 버젼에 따라 다른 커널 자료 구조들은
     다른 alignmnet들을 갖게 될것이고 다른 방법으로(함수들을 inline으로
     했느냐, 아니냐) 다른 함수들을 포함하는 것도 가능한다. 중요한 것은
     개별적인 함수 구성이 아니라 자료 구조 패딩이 달라진다는 점이다.
   - 여러분이 선택한 커널 빌드 옵션에 따라서 커널은 다양한 것들을 가정할
     수 있다.
      - 다른 구조체들은 다른 필드들을 포함할 수 있다.
      - 몇몇 함수들은 전혀 구현되지 않을 수도 있다(즉, 몇몇 lock들은
        non-SMP 빌드에서는 사라져 버릴수도 있다).
      - 커널내에 메모리는 build optoin들에 따라 다른 방법으로 align될수
        있다.
      - 리눅스는 많은 다양한 프로세서 아키텍쳐에서 실행된다. 한 아키텍쳐의
        바이너리 드라이버를 다른 아키텍쳐에서 정상적으로 실행시킬 방법은
        없다.

커널을 빌드했던 C 컴파일러와 정확하게 같은 것을 사용하고 정확하게 같은
커널 구성(configuration)을 사용하여 여러분들의 모듈을 빌드하면 간단히
많은 문제들을 해결할 수 있다. 이렇게 하는 것은 여러분들이 하나의 리눅스
배포판의 하나의 배포 버젼을 위한 모듈만을 제공한다면 별일 아닐 것이다.
그러나 각기 다른 리눅스 배포판마다 한번씩 빌드하는 수를 각 리눅스 배포판마다
제공하는 다른 릴리즈의 수와 곱하게 되면 이번에는 각 릴리즈들의 다른 빌드
옵션의 악몽과 마주하게  것이다. 또한 각 리눅스 배포판들은 다른 하드웨어
종류에(다른 프로세서 타입과 다른 옵션들) 맞춰져 있는 많은 다른 커널들을
배포한다. 그러므로 한번의 배포에서조차 여러분들의 모듈은 여러 버젼을
만들 필요가 있다.

나를 믿어라. 여러분들은 이러한 종류의 배포를 지원하려고 시도한다면 시간이
지나면 미칠지경이 될 것이다. 난 이러한 것을 오래전에 아주 어렵게 배웠다...

변하지않는 커널 소스 인터페이스들
---------------------------------

리눅스 커널 드라이버를 계속해서 메인 커널 트리에 반영하지 않고
유지보수하려고 하는 사람들과 이 문제를 논의하게 되면 훨씬 더
"논란의 여지가 많은" 주제가 될 것이다.

리눅스 커널 개발은 끊임없이 빠른 속도로 이루어지고 있으며 결코
느슨해진 적이 없다. 커널 개발자들이 현재 인터페이스들에서 버그를
발견하거나 무엇인가 할 수 있는 더 좋은 방법을 찾게 되었다고 하자.
그들이 발견한 것을 실행한다면 아마도 더 잘 동작하도록 현재 인터페이스들을
수정하게 될 것이다. 그들이 그런 일을 하게되면 함수 이름들은 변하게 되고,
구조체들은 늘어나거나 줄어들게 되고, 함수 파라미터들은 재작업될 것이다.
이러한 일이 발생되면 커널 내에 이 인터페이스를 사용했던 인스턴스들이 동시에
수정될 것이며 이러한 과정은 모든 것이 계속해서 올바르게 동작할 것이라는
것을 보장한다.

이러한 것의 한 예로써, 커널 내부의 USB 인터페이스들은 이 서브시스템이
생긴 이후로 적어도 3번의 다른 재작업을 겪었다. 이 재작업들은 많은 다른
문제들을 풀었다.
   - 데이터 스트림들의 동기적인 모델에서 비동기적인 모델로의 변화. 이것은
     많은 드라이버들의 복잡성을 줄이고 처리량을 향상시켜 현재는 거의 모든
     USB 장치들의 거의 최대 속도로 실행되고 있다.
   - USB 드라이버가 USB 코어로부터 데이터 패킷들을 할당받로록 한 변경으로
     인해서 지금의 모든 드라이버들은 많은 문서화된 데드락을 수정하기 위하여
     USB 코어에게 더 많은 정보를 제공해야만 한다.

이것은 오랫동안 자신의 오래된 USB 인터페이스들을 유지해야 하는 closed 운영체제들과는
완전히 반대되는 것이다. closed된 운영체제들은 새로운 개발자들에게 우연히 낡은
인터페이스를 사용하게 할 기회를 주게되며, 적절하지 못한 방법으로 처리하게 되어
운영체제의 안정성을 해치는 문제를 야기하게 된다.

이 두가지의 예들 모두, 모든 개발자들은 꼭 이루어져야 하는 중요한 변화들이라고
동의를 하였고 비교적 적은 고통으로 변경되어졌다. 리눅스가 변하지 않는 소스
인터페이스를 고집한다면, 새로운 인터페이스가 만들어지게 되며 반면 기존의 오래된
것들, 그리고 깨진 것들은 계속해서 유지되어야 하며 이러한 일들은 USB 개발자들에게
또 다른 일거리를 주게 된다. 모든 리눅스 USB 개발자들에게 자신의 그들의 업무를
마친 후 시간을 투자하여 아무 득도 없는 무료 봉사를 해달라고 하는 것은 가능성이
희박한 일이다.

보안 문제 역시 리눅스에게는 매우 중요하다. 보안 문제가 발견되면 그것은
매우 짧은 시간 안에 수정된다. 보안 문제는 그 문제를 해결하기 위하여
여러번 내부 커널 인터페이스들을 재작업하게 만들었다. 이러한 문제가
발생하였을 때 그 인터페이스들을 사용하는 모든 드라이버들도 동시에
수정되어 보안 문제가 앞으로 갑작스럽게 생기지는 않을 것이라는 것을
보장한다. 내부 인터페이스들의 변경이 허락되지 않으면 이러한 종류의 보안
문제를 수정하고 그것이 다시 발생하지 않을 것이라고 보장하는 것은 가능하지
않을 것이다.

커널 인터페이스들은 계속해서 정리되고 있다. 현재 인터페이스를 사용하는
사람이 한명도 없다면 그것은 삭제된다. 이것은 커널이 가능한한 가장 작게
유지되며 존재하는 모든 가능성이 있는 인터페이스들이 테스트된다는 것을
보장한다(사용되지 않는 인터페이스들은 유효성 검증을 하기가 거의 불가능하다).

무엇을 해야 하나
---------------
자, 여러분이 메인 커널 트리에 있지 않은 리눅스 커널 드라이버를 가지고
있다면 여러분은 즉, 개발자는 무엇을 해야 하나? 모든 배포판마다 다른
커널 버젼을 위한 바이너리 드라이버를 배포하는 것은 악몽이며 계속해서
변하고 있는 커널 인터페이스들의 맞처 유지보수하려고 시도하는 것은 힘든
일이다.

간단하다. 여러분의 커널 드라이버를 메인 커널 트리에 반영하라(우리는 여기서
GPL을 따르는 배포 드라이버에 관해 얘기하고 있다는 것을 상기하라. 여러분의
코드가 이러한 분류에 해당되지 않는다면 행운을 빈다. 여러분 스스로 어떻게든
해야만 한다). 여러분의 드라이버가 트리에 있게되면 커널 인터페이스가
변경되더라도 가장 먼저 커널에 변경을 가했던 사람에 의해서 수정될 것이다.
이것은 여러분의 드라이버가 여러분의 별다른 노력없이 항상 빌드가 가능하며
동작하는 것을 보장한다.

메인 커널 트리에 여러분의 드라이버를 반영하면 얻게 되는 장점들은 다음과 같다.
   - 관리에 드는 비용(원래 개발자의)은 줄어줄면서 드라이버의 질은 향상될 것이다.
   - 다른 개발자들이 여러분의 드라이버에 기능들을 추가 할 것이다.
   - 다른 사람들은 여러분의 드라이버에 버그를 발견하고 수정할 것이다.
   - 다른 사람들은 여러분의 드라이버의 개선점을 찾을 줄 것이다.
   - 외부 인터페이스 변경으로 인해 여러분의 드라이버의 수정이 필요하다면 다른
     사람들이 드라이버를 업데이트할 것이다.
   - 여러분의 드라이버는 별다른 노력 없이 모든 리눅스 배포판에  자동적으로
     추가될 것이다.

리눅스는 다른 운영 체제보다 "쉽게 쓸수 있는(out of the box)" 많은 다른 장치들을
지원하고 어떤 다른 운영 체제보다 다양한 아키텍쳐위에서 이러한 장치들을 지원하기 때문에
이러한 증명된 개발 모델은 틀림없이 바로 가고 있는 것이다.

------

이 문서의 초안을 검토해주고 코멘트 해준 Randy Dunlap, Andrew Morton, David Brownell,
Hanna Linder, Robert Love, 그리고 Nishanth Aravamudan에게 감사한다.


code:
:orphan:

.. warning::
   Si tiene alguna duda sobre la exactitud del contenido de esta
   traducción, la única referencia válida es la documentación oficial en
   inglés.

repo_name: angery/linux


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

:Original: :ref:`Documentation/process/howto.rst <process_howto>`
:Translator: Carlos Bilbao <carlos.bilbao@amd.com>

.. _sp_process_howto:

Cómo participar en el desarrollo del kernel de Linux
====================================================

Este documento es el principal punto de partida. Contiene instrucciones
sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
trabajar con el y en su desarrollo. El documento no tratará ningún aspecto
técnico relacionado con la programación del kernel, pero le ayudará
guiándole por el camino correcto.

Si algo en este documento quedara obsoleto, envíe parches al maintainer de
este archivo, que se encuentra en la parte superior del documento.

Introducción
------------
¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
Linux para este dispositivo." El objetivo de este documento en enseñarle
todo cuanto necesita para conseguir esto, describiendo el proceso por el
que debe pasar, y con indicaciones de como trabajar con la comunidad.
También trata de explicar las razones por las cuales la comunidad trabaja
de la forma en que lo hace.

El kernel esta principalmente escrito en C, con algunas partes que son
dependientes de la arquitectura en ensamblador. Un buen conocimiento de C
es necesario para desarrollar en el kernel. Lenguaje ensamblador (en
cualquier arquitectura) no es necesario excepto que planee realizar
desarrollo de bajo nivel para dicha arquitectura. Aunque no es un perfecto
sustituto para una educación sólida en C y/o años de experiencia, los
siguientes libros sirven, como mínimo, como referencia:

- "The C Programming Language" de Kernighan e Ritchie [Prentice Hall]
- "Practical C Programming" de Steve Oualline [O'Reilly]
- "C:  A Reference Manual" de Harbison and Steele [Prentice Hall]

El kernel está escrito usando GNU C y la cadena de herramientas GNU. Si
bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que
no aparecen en dicho estándar. El kernel usa un C independiente de entorno,
sin depender de la biblioteca C estándar, por lo que algunas partes del
estándar C no son compatibles. Divisiones de long long arbitrarios o
de coma flotante no son permitidas. En ocasiones, puede ser difícil de
entender las suposiciones que el kernel hace respecto a la cadena de
herramientas y las extensiones que usa, y desafortunadamente no hay
referencia definitiva para estas. Consulte las páginas de información de
gcc (`info gcc`) para obtener información al respecto.

Recuerde que está tratando de aprender a trabajar con una comunidad de
desarrollo existente. Es un grupo diverso de personas, con altos estándares
de código, estilo y procedimiento. Estas normas han sido creadas a lo
largo del tiempo en función de lo que se ha encontrado que funciona mejor
para un equipo tan grande y geográficamente disperso. Trate de aprender
tanto como le sea posible acerca de estos estándares antes de tiempo, ya
que están bien documentados; no espere que la gente se adapte a usted o a
la forma de hacer las cosas en su empresa.

Cuestiones legales
------------------
El código fuente del kernel de Linux se publica bajo licencia GPL. Por
favor, revise el archivo COPYING, presente en la carpeta principal del
código fuente, para detalles de la licencia. Si tiene alguna otra pregunta
sobre licencias, contacte a un abogado, no pregunte en listas de discusión
del kernel de Linux. La gente en estas listas no son abogadas, y no debe
confiar en sus opiniones en materia legal.

Para preguntas y respuestas más frecuentes sobre la licencia GPL, consulte:

	https://www.gnu.org/licenses/gpl-faq.html

Documentación
--------------
El código fuente del kernel de Linux tiene una gran variedad de documentos
que son increíblemente valiosos para aprender a interactuar con la
comunidad del kernel. Cuando se agregan nuevas funciones al kernel, se
recomienda que se incluyan nuevos archivos de documentación que expliquen
cómo usar la función. Cuando un cambio en el kernel hace que la interfaz
que el kernel expone espacio de usuario cambie, se recomienda que envíe la
información o un parche en las páginas del manual que expliquen el cambio
a mtk.manpages@gmail.com, y CC la lista linux-api@vger.kernel.org.

Esta es la lista de archivos que están en el código fuente del kernel y son
de obligada lectura:

  :ref:`Documentation/admin-guide/README.rst <readme>`
    Este archivo ofrece una breve descripción del kernel de Linux y
    describe lo que es necesario hacer para configurar y compilar el
    kernel. Quienes sean nuevos en el kernel deben comenzar aquí.

  :ref:`Documentation/process/changes.rst <changes>`
    Este archivo proporciona una lista de los niveles mínimos de varios
    paquetes que son necesarios para construir y ejecutar el kernel
    exitosamente.

  :ref:`Documentation/process/coding-style.rst <codingstyle>`
    Esto describe el estilo de código del kernel de Linux y algunas de los
    razones detrás de esto. Se espera que todo el código nuevo siga las
    directrices de este documento. La mayoría de los maintainers solo
    aceptarán parches si se siguen estas reglas, y muchas personas solo
    revisan el código si tiene el estilo adecuado.

  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
    Este archivo describe en gran detalle cómo crear con éxito y enviar un
    parche, que incluye (pero no se limita a):

       - Contenidos del correo electrónico (email)
       - Formato del email
       - A quien se debe enviar

    Seguir estas reglas no garantiza el éxito (ya que todos los parches son
    sujetos a escrutinio de contenido y estilo), pero en caso de no seguir
    dichas reglas, el fracaso es prácticamente garantizado.
    Otras excelentes descripciones de cómo crear parches correctamente son:

	"The Perfect Patch"
		https://www.ozlabs.org/~akpm/stuff/tpp.txt

	"Linux kernel patch submission format"
		https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html

  :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
    Este archivo describe la lógica detrás de la decisión consciente de
    no tener una API estable dentro del kernel, incluidas cosas como:

      - Capas intermedias del subsistema (por compatibilidad?)
      - Portabilidad de drivers entre sistemas operativos
      - Mitigar el cambio rápido dentro del árbol de fuentes del kernel (o
        prevenir cambios rápidos)

     Este documento es crucial para comprender la filosofía del desarrollo
     de Linux y es muy importante para las personas que se mudan a Linux
     tras desarrollar otros sistemas operativos.

  :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`
    Si cree que ha encontrado un problema de seguridad en el kernel de
    Linux, siga los pasos de este documento para ayudar a notificar a los
    desarrolladores del kernel y ayudar a resolver el problema.

  :ref:`Documentation/process/management-style.rst <managementstyle>`
    Este documento describe cómo operan los maintainers del kernel de Linux
    y los valores compartidos detrás de sus metodologías. Esta es una
    lectura importante para cualquier persona nueva en el desarrollo del
    kernel (o cualquier persona que simplemente sienta curiosidad por
    el campo IT), ya que clarifica muchos conceptos erróneos y confusiones
    comunes sobre el comportamiento único de los maintainers del kernel.

  :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
    Este archivo describe las reglas sobre cómo se suceden las versiones
    del kernel estable, y qué hacer si desea obtener un cambio en una de
    estas publicaciones.

  :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
    Una lista de documentación externa relativa al desarrollo del kernel.
    Por favor consulte esta lista si no encuentra lo que están buscando
    dentro de la documentación del kernel.

  :ref:`Documentation/process/applying-patches.rst <applying_patches>`
    Una buena introducción que describe exactamente qué es un parche y cómo
    aplicarlo a las diferentes ramas de desarrollo del kernel.

El kernel también tiene una gran cantidad de documentos que pueden ser
generados automáticamente desde el propio código fuente o desde
ReStructuredText markups (ReST), como este. Esto incluye un descripción
completa de la API en el kernel y reglas sobre cómo manejar cerrojos
(locking) correctamente.

Todos estos documentos se pueden generar como PDF o HTML ejecutando::

	make pdfdocs
	make htmldocs

respectivamente desde el directorio fuente principal del kernel.

Los documentos que utilizan el markup ReST se generarán en
Documentation/output. También se pueden generar en formatos LaTeX y ePub
con::

	make latexdocs
	make epubdocs

Convertirse en un/a desarrollador/a de kernel
---------------------------------------------

Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
el proyecto Linux KernelNewbies:

	https://kernelnewbies.org

Consiste en una útil lista de correo donde puede preguntar casi cualquier
tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en
los archivos primero, antes de preguntar algo que ya ha sido respondido en
el pasado.) También tiene un canal IRC que puede usar para hacer preguntas
en tiempo real, y una gran cantidad de documentación útil para ir
aprendiendo sobre el desarrollo del kernel de Linux.

El sitio web tiene información básica sobre la organización del código,
subsistemas, y proyectos actuales (tanto dentro como fuera del árbol).
También describe alguna información logística básica, como cómo compilar
un kernel y aplicar un parche.

Si no sabe por dónde quiere empezar, pero quieres buscar alguna tarea que
comenzar a hacer para unirse a la comunidad de desarrollo del kernel,
acuda al proyecto Linux Kernel Janitor:

	https://kernelnewbies.org/KernelJanitors

Es un gran lugar para comenzar. Describe una lista de problemas
relativamente simples que deben limpiarse y corregirse dentro del código
fuente del kernel de Linux árbol de fuentes. Trabajando con los
desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos
para incluir su parche en el árbol del kernel de Linux, y posiblemente
descubrir en la dirección en que trabajar a continuación, si no tiene ya
una idea.

Antes de realizar cualquier modificación real al código del kernel de
Linux, es imperativo entender cómo funciona el código en cuestión. Para
este propósito, nada es mejor que leerlo directamente (lo más complicado
está bien comentado), tal vez incluso con la ayuda de herramientas
especializadas. Una de esas herramientas que se recomienda especialmente
es el proyecto Linux Cross-Reference, que es capaz de presentar el código
fuente en un formato de página web indexada y autorreferencial. Una
excelente puesta al día del repositorio del código del kernel se puede
encontrar en:

	https://elixir.bootlin.com/

El proceso de desarrollo
------------------------

El proceso de desarrollo del kernel de Linux consiste actualmente de
diferentes "branches" (ramas) con muchos distintos subsistemas específicos
a cada una de ellas. Las diferentes ramas son:

  - El código principal de Linus (mainline tree)
  - Varios árboles estables con múltiples major numbers
  - Subsistemas específicos
  - linux-next, para integración y testing

Mainline tree (Árbol principal)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en
https://kernel.org o en su repo.  El proceso de desarrollo es el siguiente:

  - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos
    semanas, durante este período de tiempo, los maintainers pueden enviar
    grandes modificaciones a Linus, por lo general los parches que ya se
    han incluido en el linux-next durante unas semanas. La forma preferida
    de enviar grandes cambios es usando git (la herramienta de
    administración de código fuente del kernel, más información al respecto
    en https://git-scm.com/), pero los parches simples también son validos.
  - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra
    en hacer el kernel nuevo lo más estable ("solido") posible. La mayoría
    de los parches en este punto deben arreglar una regresión. Los errores
    que siempre han existido no son regresiones, por lo tanto, solo envíe
    este tipo de correcciones si son importantes. Tenga en cuenta que se
    podría aceptar un controlador (o sistema de archivos) completamente
    nuevo después de -rc1 porque no hay riesgo de causar regresiones con
    tal cambio, siempre y cuando el cambio sea autónomo y no afecte áreas
    fuera del código que se está agregando. git se puede usar para enviar
    parches a Linus después de que se lance -rc1, pero los parches también
    deben ser enviado a una lista de correo pública para su revisión.
  - Se lanza un nuevo -rc cada vez que Linus considera que el árbol git
    actual esta en un estado razonablemente sano y adecuado para la prueba.
    La meta es lanzar un nuevo kernel -rc cada semana.
  - El proceso continúa hasta que el kernel se considera "listo", y esto
    puede durar alrededor de 6 semanas.

Vale la pena mencionar lo que Andrew Morton escribió en las listas de
correo del kernel de Linux, sobre lanzamientos del kernel (traducido):

	*"Nadie sabe cuándo se publicara un nuevo kernel, pues esto sucede
	según el estado de los bugs, no de una cronología preconcebida."*

Varios árboles estables con múltiples major numbers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Los kernels con versiones de 3 partes son kernels estables. Estos contienen
correcciones relativamente pequeñas y críticas para problemas de seguridad
o importantes regresiones descubiertas para una publicación de código.
Cada lanzamiento en una gran serie estable incrementa la tercera parte de
la versión número, manteniendo las dos primeras partes iguales.

Esta es la rama recomendada para los usuarios que quieren la versión
estable más reciente del kernel, y no están interesados en ayudar a probar
versiones en desarrollo/experimentales.

Los árboles estables son mantenidos por el equipo "estable"
<stable@vger.kernel.org>, y se liberan (publican) según lo dicten las
necesidades. El período de liberación normal es de aproximadamente dos
semanas, pero puede ser más largo si no hay problemas apremiantes. Un
problema relacionado con la seguridad, en cambio, puede causar un
lanzamiento casi instantáneamente.

El archivo :ref:`Documentación/proceso/stable-kernel-rules.rst <stable_kernel_rules>`
en el árbol del kernel documenta qué tipos de cambios son aceptables para
el árbol estable y cómo funciona el proceso de lanzamiento.

Subsistemas específicos
~~~~~~~~~~~~~~~~~~~~~~~~
Los maintainers de los diversos subsistemas del kernel --- y también muchos
desarrolladores de subsistemas del kernel --- exponen su estado actual de
desarrollo en repositorios fuente. De esta manera, otros pueden ver lo que
está sucediendo en las diferentes áreas del kernel. En áreas donde el
desarrollo es rápido, se le puede pedir a un desarrollador que base sus
envíos en tal árbol del subsistema del kernel, para evitar conflictos entre
este y otros trabajos ya en curso.

La mayoría de estos repositorios son árboles git, pero también hay otros
SCM en uso, o colas de parches que se publican como series quilt. Las
direcciones de estos repositorios de subsistemas se enumeran en el archivo
MAINTAINERS. Muchos de estos se pueden ver en https://git.kernel.org/.

Antes de que un parche propuesto se incluya con dicho árbol de subsistemas,
es sujeto a revisión, que ocurre principalmente en las listas de correo
(ver la sección respectiva a continuación). Para varios subsistemas del
kernel, esta revisión se rastrea con la herramienta patchwork. Patchwork
ofrece una interfaz web que muestra publicaciones de parches, cualquier
comentario sobre un parche o revisiones a él, y los maintainers pueden
marcar los parches como en revisión, aceptado, o rechazado. La mayoría de
estos sitios de trabajo de parches se enumeran en

https://patchwork.kernel.org/.

linux-next, para integración y testing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Antes de que las actualizaciones de los árboles de subsistemas se combinen
con el árbol principal, necesitan probar su integración. Para ello, existe
un repositorio especial de pruebas en el que se encuentran casi todos los
árboles de subsistema, actualizado casi a diario:

	https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git

De esta manera, linux-next ofrece una perspectiva resumida de lo que se
espera que entre en el kernel principal en el próximo período de "merge"
(fusión de código). Los testers aventureros son bienvenidos a probar
linux-next en ejecución.

Reportar bugs
-------------

El archivo 'Documentación/admin-guide/reporting-issues.rst' en el
directorio principal del kernel describe cómo informar un posible bug del
kernel y detalles sobre qué tipo de información necesitan los
desarrolladores del kernel para ayudar a rastrear la fuente del problema.

Gestión de informes de bugs
------------------------------

Una de las mejores formas de poner en práctica sus habilidades de hacking
es arreglando errores reportados por otras personas. No solo ayudará a
hacer el kernel más estable, también aprenderá a solucionar problemas del
mundo real y mejora sus habilidades, y otros desarrolladores se darán
cuenta de tu presencia. La corrección de errores es una de las mejores
formas de ganar méritos entre desarrolladores, porque no a muchas personas
les gusta perder el tiempo arreglando los errores de otras personas.

Para trabajar en informes de errores ya reportados, busque un subsistema
que le interese. Verifique el archivo MAINTAINERS donde se informan los
errores de ese subsistema; con frecuencia será una lista de correo, rara
vez un rastreador de errores (bugtracker). Busque en los archivos de dicho
lugar para informes recientes y ayude donde lo crea conveniente. También es
posible que desee revisar https://bugzilla.kernel.org para informes de
errores; solo un puñado de subsistemas del kernel lo emplean activamente
para informar o rastrear; sin embargo, todos los errores para todo el kernel
se archivan allí.

Listas de correo
-----------------

Como se explica en algunos de los documentos anteriores, la mayoría de
desarrolladores del kernel participan en la lista de correo del kernel de
Linux. Detalles sobre cómo para suscribirse y darse de baja de la lista se
pueden encontrar en:

	http://vger.kernel.org/vger-lists.html#linux-kernel

Existen archivos de la lista de correo en la web en muchos lugares
distintos. Utilice un motor de búsqueda para encontrar estos archivos. Por
ejemplo:

	http://dir.gmane.org/gmane.linux.kernel

Es muy recomendable que busque en los archivos sobre el tema que desea
tratar, antes de publicarlo en la lista. Un montón de cosas ya discutidas
en detalle solo se registran en los archivos de la lista de correo.

La mayoría de los subsistemas individuales del kernel también tienen sus
propias lista de correo donde hacen sus esfuerzos de desarrollo. Revise el
archivo MAINTAINERS para obtener referencias de lo que estas listas para
los diferentes grupos.

Muchas de las listas están alojadas en kernel.org. La información sobre
estas puede ser encontrada en:

	http://vger.kernel.org/vger-lists.html

Recuerde mantener buenos hábitos de comportamiento al usar las listas.
Aunque un poco cursi, la siguiente URL tiene algunas pautas simples para
interactuar con la lista (o cualquier lista):

	http://www.albion.com/netiquette/

Si varias personas responden a su correo, el CC (lista de destinatarios)
puede hacerse bastante grande. No elimine a nadie de la lista CC: sin una
buena razón, o no responda solo a la dirección de la lista. Acostúmbrese
a recibir correos dos veces, una del remitente y otra de la lista, y no
intente ajustar esto agregando encabezados de correo astutos, a la gente no
le gustará.

Recuerde mantener intacto el contexto y la atribución de sus respuestas,
mantenga las líneas "El hacker John Kernel escribió ...:" en la parte
superior de su respuesta, y agregue sus declaraciones entre las secciones
individuales citadas en lugar de escribiendo en la parte superior del
correo electrónico.

Si incluye parches en su correo, asegúrese de que sean texto legible sin
formato como se indica en :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
Los desarrolladores del kernel no quieren lidiar con archivos adjuntos o
parches comprimidos; y pueden querer comentar líneas individuales de su
parche, que funciona sólo de esa manera. Asegúrese de emplear un programa
de correo que no altere los espacios ni los tabuladores. Una buena primera
prueba es enviarse el correo a usted mismo, e intentar aplicar su
propio parche. Si eso no funciona, arregle su programa de correo o
reemplace hasta que funcione.

Sobretodo, recuerde de ser respetuoso con otros subscriptores.

Colaborando con la comunidad
----------------------------

El objetivo de la comunidad del kernel es proporcionar el mejor kernel
posible. Cuando envíe un parche para su aceptación, se revisará en sus
méritos técnicos solamente. Entonces, ¿qué deberías ser?

  - críticas
  - comentarios
  - peticiones de cambios
  - peticiones de justificaciones
  - silencio

Recuerde, esto es parte de introducir su parche en el kernel. Tiene que ser
capaz de recibir críticas y comentarios sobre sus parches, evaluar
a nivel técnico y re-elaborar sus parches o proporcionar razonamiento claro
y conciso de por qué no se deben hacer tales cambios. Si no hay respuestas
a su publicación, espere unos días e intente de nuevo, a veces las cosas se
pierden dado el gran volumen.

¿Qué no debería hacer?

  - esperar que su parche se acepte sin preguntas
  - actuar de forma defensiva
  - ignorar comentarios
  - enviar el parche de nuevo, sin haber aplicados los cambios pertinentes

En una comunidad que busca la mejor solución técnica posible, siempre habrá
diferentes opiniones sobre lo beneficioso que es un parche. Tiene que ser
cooperativo y estar dispuesto a adaptar su idea para que encaje dentro
del kernel, o al menos esté dispuesto a demostrar que su idea vale la pena.
Recuerde, estar equivocado es aceptable siempre y cuando estés dispuesto a
trabajar hacia una solución que sea correcta.

Es normal que las respuestas a su primer parche sean simplemente una lista
de una docena de cosas que debe corregir. Esto **no** implica que su
parche no será aceptado, y **no** es personal. Simplemente corrija todos
los problemas planteados en su parche, y envié otra vez.

Diferencias entre la comunidad kernel y las estructuras corporativas
--------------------------------------------------------------------

La comunidad del kernel funciona de manera diferente a la mayoría de los
entornos de desarrollo tradicionales en empresas. Aquí hay una lista de
cosas que puede intentar hacer para evitar problemas:

  Cosas buenas que decir respecto a los cambios propuestos:

    - "Esto arregla múltiples problemas."
    - "Esto elimina 2000 lineas de código."
    - "Aquí hay un parche que explica lo que intento describir."
    - "Lo he testeado en 5 arquitecturas distintas..."
    - "Aquí hay una serie de parches menores que..."
    - "Esto mejora el rendimiento en maquinas típicas..."

  Cosas negativas que debe evitar decir:

    - "Lo hicimos así en AIX/ptx/Solaris, de modo que debe ser bueno..."
    - "Llevo haciendo esto 20 años, de modo que..."
    - "Esto lo necesita mi empresa para ganar dinero"
    - "Esto es para la linea de nuestros productos Enterprise"
    - "Aquí esta el documento de 1000 paginas describiendo mi idea"
    - "Llevo 6 meses trabajando en esto..."
    - "Aquí esta un parche de 5000 lineas que..."
    - "He rescrito todo el desastre actual, y aquí esta..."
    - "Tengo un deadline, y este parche debe aplicarse ahora."

Otra forma en que la comunidad del kernel es diferente a la mayoría de los
entornos de trabajo tradicionales en ingeniería de software, es la
naturaleza sin rostro de interacción. Una de las ventajas de utilizar el
correo electrónico y el IRC como formas principales de comunicación es la
no discriminación por motivos de género o raza. El entorno de trabajo del
kernel de Linux acepta a mujeres y minorías porque todo lo que eres es una
dirección de correo electrónico. El aspecto internacional también ayuda a
nivelar el campo de juego porque no puede adivinar el género basado en
el nombre de una persona. Un hombre puede llamarse Andrea y una mujer puede
llamarse Pat. La mayoría de las mujeres que han trabajado en el kernel de
Linux y han expresado una opinión han tenido experiencias positivas.

La barrera del idioma puede causar problemas a algunas personas que no se
sientes cómodas con el inglés. Un buen dominio del idioma puede ser
necesario para transmitir ideas correctamente en las listas de correo, por
lo que le recomendamos que revise sus correos electrónicos para asegurarse
de que tengan sentido en inglés antes de enviarlos.

Divida sus cambios
---------------------

La comunidad del kernel de Linux no acepta con gusto grandes fragmentos de
código, sobretodo a la vez. Los cambios deben introducirse correctamente,
discutidos y divididos en pequeñas porciones individuales. Esto es casi
exactamente lo contrario de lo que las empresas están acostumbradas a hacer.
Su propuesta también debe introducirse muy temprano en el proceso de
desarrollo, de modo que pueda recibir comentarios sobre lo que está
haciendo. También deje que la comunidad sienta que está trabajando con
ellos, y no simplemente usándolos como un vertedero para su función. Sin
embargo, no envíe 50 correos electrónicos a una vez a una lista de correo,
su serie de parches debe casi siempre ser más pequeña que eso.

Las razones para dividir las cosas son las siguientes:

1) Los cambios pequeños aumentan la probabilidad de que sus parches sean
   aplicados, ya que no requieren mucho tiempo o esfuerzo para verificar su
   exactitud. Un parche de 5 líneas puede ser aplicado por un maintainer
   con apenas una segunda mirada. Sin embargo, un parche de 500 líneas
   puede tardar horas en ser revisado en términos de corrección (el tiempo
   que toma es exponencialmente proporcional al tamaño del parche, o algo
   así).

   Los parches pequeños también facilitan la depuración cuando algo falla.
   Es mucho más fácil retirar los parches uno por uno que diseccionar un
   parche muy grande después de haber sido aplicado (y roto alguna cosa).

2) Es importante no solo enviar pequeños parches, sino también reescribir
   y simplificar (o simplemente reordenar) los parches antes de enviarlos.

Esta es una analogía del desarrollador del kernel Al Viro (traducida):

	*"Piense en un maestro que califica la tarea de un estudiante de
	matemáticas. El maestro no quiere ver los intentos y errores del
	estudiante antes de que se les ocurriera la solución. Quiere ver la
	respuesta más limpia y elegante. Un buen estudiante lo sabe, y nunca
	presentaría su trabajo intermedio antes de tener la solución final.*

	*Lo mismo ocurre con el desarrollo del kernel. Los maintainers y
	revisores no quieren ver el proceso de pensamiento detrás de la solución
	al problema que se está resolviendo. Quieren ver un solución simple y
	elegante."*

Puede resultar un reto mantener el equilibrio entre presentar una solución
elegante y trabajar junto a la comunidad, discutiendo su trabajo inacabado.
Por lo tanto, es bueno comenzar temprano en el proceso para obtener
"feedback" y mejorar su trabajo, pero también mantenga sus cambios en
pequeños trozos que pueden ser aceptados, incluso cuando toda su labor no
está listo para inclusión en un momento dado.

También tenga en cuenta que no es aceptable enviar parches para su
inclusión que están sin terminar y serán "arreglados más tarde".

Justifique sus cambios
----------------------

Además de dividir sus parches, es muy importante que deje a la comunidad de
Linux sabe por qué deberían agregar este cambio. Nuevas características
debe justificarse como necesarias y útiles.

Documente sus cambios
---------------------

Cuando envíe sus parches, preste especial atención a lo que dice en el
texto de su correo electrónico. Esta información se convertirá en el
ChangeLog del parche, y se conservará para que todos la vean, todo el
tiempo. Debe describir el parche por completo y contener:

  - por qué los cambios son necesarios
  - el diseño general de su propuesta
  - detalles de implementación
  - resultados de sus experimentos

Para obtener más detalles sobre cómo debería quedar todo esto, consulte la
sección ChangeLog del documento:

  "The Perfect Patch"
      https://www.ozlabs.org/~akpm/stuff/tpp.txt

Todas estas cuestiones son a veces son muy difíciles de conseguir. Puede
llevar años perfeccionar estas prácticas (si es que lo hace). Es un proceso
continuo de mejora que requiere mucha paciencia y determinación. Pero no se
rinda, es posible. Muchos lo han hecho antes, y cada uno tuvo que comenzar
exactamente donde está usted ahora.

----------

Gracias a Paolo Ciarrocchi que permitió que la sección "Development Process"
se basara en el texto que había escrito (https://lwn.net/Articles/94386/),
y a Randy Dunlap y Gerrit Huizenga por algunas de la lista de cosas que
debes y no debes decir. También gracias a Pat Mochel, Hanna Linder, Randy
Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook,
Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk,
Keri Harris, Frans Pop, David A. Wheeler, Junio Hamano, Michael Kerrisk y
Alex Shepard por su revisión, comentarios y contribuciones. Sin su ayuda,
este documento no hubiera sido posible.

Maintainer: Greg Kroah-Hartman <greg@kroah.com>


code:
=====================
Traducción al español
=====================

.. raw:: latex

	\kerneldocCJKoff

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

.. _sp_disclaimer:

Advertencia
===========

El objetivo de esta traducción es facilitar la lectura y comprensión para
aquellos que no entiendan inglés o duden de sus interpretaciones, o
simplemente para aquellos que prefieran leer en el idioma español. Sin
embargo, tenga en cuenta que la *única* documentación oficial es la que
está en inglés: :ref:`linux_doc`

La propagación simultánea de la traducción de una modificación en
:ref:`linux_doc` es altamente improbable. Los maintainers y colaboradores
de la traducción intentan mantener sus traducciones al día, en tanto les
es posible. Por tanto, no existe ninguna garantía de que una traducción
esté actualizada con las últimas modificaciones. Si lo que lee en una
traducción no se corresponde con lo que ve en el código fuente, informe
al maintainer de la traducción y, si puede, consulte la documentación en
inglés.

Una traducción no es una * bifurcación * de la documentación oficial, por
lo que los usuarios no encontrarán aquí ninguna información que no sea la
versión oficial. Cualquier adición, supresión o modificación de los
contenidos deberá ser realizada anteriormente en los documentos en inglés.
Posteriormente, y cuando sea posible, dicho cambio debería aplicarse
también a las traducciones. Los maintainers de las traducciones aceptan
contribuciones que son puramente de interés relativo a la traducción (por
ejemplo, nuevas traducciones, actualizaciones, correcciones, etc.).

Las traducciones tratan de ser lo más precisas posible pero no es posible
convertir directamente un idioma a otro. Cada idioma tiene su propia
gramática, y una cultura tras ella, por lo tanto, la traducción de una
oración al inglés se podría modificar para adaptarla al español. Por esta
razón, cuando lea esta traducción, puede encontrar algunas diferencias en
la forma, pero todavía transmiten el mensaje original. A pesar de la gran
difusión del inglés en el idioma hablado, cuando sea posible, expresiones
en inglés serán reemplazadas por las palabras correspondientes en español.

Si necesita ayuda para comunicarse con la comunidad de Linux pero no se
siente cómodo escribiendo en inglés, puede pedir ayuda al maintainer para
obtener una traducción.

Muchos países hablan español, cada uno con su propia cultura, expresiones,
y diferencias gramaticales en ocasiones significativas. Las traducciones de
los maintainers pueden utilizar el español con el que dichos maintainers se
sientan más cómodos. En principio, estas pequeñas diferencias no deberían
suponer una gran barrera para hablantes de distintas versiones del español,
pero en caso de duda se puede consultar a los maintainers.

La documentación del kernel Linux
=================================

Este es el nivel superior de la documentación del kernel en idioma español.
La traducción es incompleta, y podría encontrar advertencias que indiquen
la falta de una traducción o de un grupo de traducciones.

En términos más generales, la documentación, como el kernel mismo, están en
constante desarrollo. Las mejoras en la documentación siempre son
bienvenidas; de modo que, si desea ayudar, únase a la lista de correo
linux-doc en vger.kernel.org.

Traducciones al español
=======================

.. toctree::
   :maxdepth: 1

   howto
   process/index
   wrappers/memory-barriers