1 .. SPDX-License-Identifier: GPL-2.0 1 .. SPDX-License-Identifier: GPL-2.0
2 2
3 :Original: :ref:`Documentation/process/researc 3 :Original: :ref:`Documentation/process/researcher-guidelines.rst`
4 :Translator: Avadhut Naik <avadhut.naik@amd.com 4 :Translator: Avadhut Naik <avadhut.naik@amd.com>
5 5
6 Directrices para Investigadores 6 Directrices para Investigadores
7 ++++++++++++++++++++++++++++++++ 7 ++++++++++++++++++++++++++++++++
8 8
9 La comunidad del kernel de Linux da la bienven 9 La comunidad del kernel de Linux da la bienvenida a la investigación
10 transparente sobre el kernel de Linux, las act 10 transparente sobre el kernel de Linux, las actividades involucradas
11 en su producción, otros subproductos de su de 11 en su producción, otros subproductos de su desarrollo. Linux se
12 beneficia mucho de este tipo de investigación 12 beneficia mucho de este tipo de investigación, y la mayoría de los
13 aspectos de Linux son impulsados por investiga 13 aspectos de Linux son impulsados por investigación en una forma u otra.
14 14
15 La comunidad agradece mucho si los investigado 15 La comunidad agradece mucho si los investigadores pueden compartir
16 los hallazgos preliminares antes de hacer púb 16 los hallazgos preliminares antes de hacer públicos sus resultados,
17 especialmente si tal investigación involucra 17 especialmente si tal investigación involucra seguridad. Involucrarse
18 temprano ayuda a mejorar la calidad de investi 18 temprano ayuda a mejorar la calidad de investigación y la capacidad
19 de Linux para mejorar a partir de ella. En cua 19 de Linux para mejorar a partir de ella. En cualquier caso, se recomienda
20 compartir copias de acceso abierto de la inves 20 compartir copias de acceso abierto de la investigación publicada con
21 la comunidad. 21 la comunidad.
22 22
23 Este documento busca clarificar lo que la comu 23 Este documento busca clarificar lo que la comunidad del kernel de Linux
24 considera practicas aceptables y no aceptables 24 considera practicas aceptables y no aceptables al llevar a cabo
25 investigación de este tipo. Por lo menos, dic 25 investigación de este tipo. Por lo menos, dicha investigación y
26 actividades afines deben seguir las reglas est 26 actividades afines deben seguir las reglas estándar de ética de la
27 investigación. Para más información sobre l 27 investigación. Para más información sobre la ética de la investigación
28 en general, ética en la tecnología y la inve 28 en general, ética en la tecnología y la investigación de las comunidades
29 de desarrolladores en particular, ver: 29 de desarrolladores en particular, ver:
30 30
31 31
32 * `Historia de la Ética en la Investigación 32 * `Historia de la Ética en la Investigación <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
33 * `Ética de la IEEE <https://www.ieee.org/abo 33 * `Ética de la IEEE <https://www.ieee.org/about/ethics/index.html>`_
34 * `Perspectivas de Desarrolladores e Investiga 34 * `Perspectivas de Desarrolladores e Investigadores sobre la Ética de los Experimentos en Proyectos de Código Abierto <https://arxiv.org/pdf/2112.13217.pdf>`_
35 35
36 La comunidad del kernel de Linux espera que to 36 La comunidad del kernel de Linux espera que todos los que interactúan con
37 el proyecto están participando en buena fe pa 37 el proyecto están participando en buena fe para mejorar Linux. La
38 investigación sobre cualquier artefacto dispo 38 investigación sobre cualquier artefacto disponible públicamente (incluido,
39 pero no limitado a código fuente) producido p 39 pero no limitado a código fuente) producido por la comunidad del kernel
40 de Linux es bienvenida, aunque la investigaci 40 de Linux es bienvenida, aunque la investigación sobre los desarrolladores
41 debe ser claramente opcional. 41 debe ser claramente opcional.
42 42
43 La investigación pasiva que se basa completam 43 La investigación pasiva que se basa completamente en fuentes disponibles
44 públicamente, incluidas las publicaciones en 44 públicamente, incluidas las publicaciones en listas de correo públicas y
45 las contribuciones a los repositorios público 45 las contribuciones a los repositorios públicos, es claramente permitida.
46 Aunque, como con cualquier investigación, tod 46 Aunque, como con cualquier investigación, todavía se debe seguir la ética
47 estándar. 47 estándar.
48 48
49 La investigación activa sobre el comportamien 49 La investigación activa sobre el comportamiento de los desarrolladores,
50 sin embargo, debe hacerse con el acuerdo expl 50 sin embargo, debe hacerse con el acuerdo explícito y la divulgación
51 completa a los desarrolladores individuales in 51 completa a los desarrolladores individuales involucrados. No se puede
52 interactuar / experimentar con los desarrollad 52 interactuar / experimentar con los desarrolladores sin consentimiento;
53 esto también es ética de investigación est 53 esto también es ética de investigación estándar.
54 54
55 Para ayudar a aclarar: enviar parches a los de 55 Para ayudar a aclarar: enviar parches a los desarrolladores es interactuar
56 con ellos, pero ya han dado su consentimiento 56 con ellos, pero ya han dado su consentimiento para recibir contribuciones
57 en buena fe. No se ha dado consentimiento para 57 en buena fe. No se ha dado consentimiento para enviar parches intencionalmente
58 defectuosos / vulnerables o contribuir con la 58 defectuosos / vulnerables o contribuir con la información engañosa a las
59 discusiones. Dicha comunicación puede ser per 59 discusiones. Dicha comunicación puede ser perjudicial al desarrollador (por
60 ejemplo, agotar el tiempo, el esfuerzo, y la m 60 ejemplo, agotar el tiempo, el esfuerzo, y la moral) y perjudicial para el
61 proyecto al erosionar la confianza de toda la 61 proyecto al erosionar la confianza de toda la comunidad de desarrolladores en
62 el colaborador (y la organización del colabor 62 el colaborador (y la organización del colaborador en conjunto), socavando
63 los esfuerzos para proporcionar reacciones con 63 los esfuerzos para proporcionar reacciones constructivas a los colaboradores
64 y poniendo a los usuarios finales en riesgo de 64 y poniendo a los usuarios finales en riesgo de fallas de software.
65 65
66 La participación en el desarrollo de Linux en 66 La participación en el desarrollo de Linux en sí mismo por parte de
67 investigadores, como con cualquiera, es bienve 67 investigadores, como con cualquiera, es bienvenida y alentada. La
68 investigación del código de Linux es una pr 68 investigación del código de Linux es una práctica común, especialmente
69 cuando se trata de desarrollar o ejecutar herr 69 cuando se trata de desarrollar o ejecutar herramientas de análisis que
70 producen resultados procesables. 70 producen resultados procesables.
71 71
72 Cuando se interactúa con la comunidad de desa 72 Cuando se interactúa con la comunidad de desarrolladores, enviar un
73 parche ha sido tradicionalmente la mejor maner 73 parche ha sido tradicionalmente la mejor manera para hacer un impacto.
74 Linux ya tiene muchos errores conocidos – lo 74 Linux ya tiene muchos errores conocidos – lo que es mucho más útil es
75 tener soluciones verificadas. Antes de contrib 75 tener soluciones verificadas. Antes de contribuir, lea cuidadosamente
76 la documentación adecuada. 76 la documentación adecuada.
77 77
78 * Documentation/process/development-process.rs 78 * Documentation/process/development-process.rst
79 * Documentation/process/submitting-patches.rst 79 * Documentation/process/submitting-patches.rst
80 * Documentation/admin-guide/reporting-issues.r 80 * Documentation/admin-guide/reporting-issues.rst
81 * Documentation/process/security-bugs.rst 81 * Documentation/process/security-bugs.rst
82 82
83 Entonces envíe un parche (incluyendo un regis 83 Entonces envíe un parche (incluyendo un registro de confirmación con
84 todos los detalles enumerados abajo) y haga un 84 todos los detalles enumerados abajo) y haga un seguimiento de cualquier
85 comentario de otros desarrolladores. 85 comentario de otros desarrolladores.
86 86
87 * ¿Cuál es el problema específico que se ha 87 * ¿Cuál es el problema específico que se ha encontrado?
88 * ¿Como podría llegar al problema en un sist 88 * ¿Como podría llegar al problema en un sistema en ejecución?
89 * ¿Qué efecto tendría encontrar el problema 89 * ¿Qué efecto tendría encontrar el problema en el sistema?
90 * ¿Como se encontró el problema? Incluya esp 90 * ¿Como se encontró el problema? Incluya específicamente detalles sobre
91 cualquier prueba, programas de análisis est 91 cualquier prueba, programas de análisis estáticos o dinámicos, y cualquier
92 otra herramienta o método utilizado para re 92 otra herramienta o método utilizado para realizar el trabajo.
93 * ¿En qué versión de Linux se encontró el 93 * ¿En qué versión de Linux se encontró el problema? Se prefiere usar la
94 versión más reciente o una rama reciente d 94 versión más reciente o una rama reciente de linux-next (ver
95 Documentation/process/howto.rst). 95 Documentation/process/howto.rst).
96 * ¿Que se cambió para solucionar el problema 96 * ¿Que se cambió para solucionar el problema y por qué se cree es correcto?
97 * ¿Como se probó el cambio para la complicac 97 * ¿Como se probó el cambio para la complicación y el tiempo de ejecución?
98 * ¿Qué confirmación previa corrige este cam 98 * ¿Qué confirmación previa corrige este cambio? Esto debería ir en un “Fixes:”
99 etiqueta como se describe en la documentaci 99 etiqueta como se describe en la documentación.
100 * ¿Quién más ha revisado este parche? Esto 100 * ¿Quién más ha revisado este parche? Esto debería ir con la adecuada “Reviewed-by”
101 etiqueta; Vea abajo. 101 etiqueta; Vea abajo.
102 102
103 Por ejemplo (en inglés, pues es en las listas 103 Por ejemplo (en inglés, pues es en las listas)::
104 104
105 From: Author <author@email> 105 From: Author <author@email>
106 Subject: [PATCH] drivers/foo_bar: Add missin 106 Subject: [PATCH] drivers/foo_bar: Add missing kfree()
107 107
108 The error path in foo_bar driver does not co 108 The error path in foo_bar driver does not correctly free the allocated
109 struct foo_bar_info. This can happen if the 109 struct foo_bar_info. This can happen if the attached foo_bar device
110 rejects the initialization packets sent duri 110 rejects the initialization packets sent during foo_bar_probe(). This
111 would result in a 64 byte slab memory leak o 111 would result in a 64 byte slab memory leak once per device attach,
112 wasting memory resources over time. 112 wasting memory resources over time.
113 113
114 This flaw was found using an experimental st 114 This flaw was found using an experimental static analysis tool we are
115 developing, LeakMagic[1], which reported the 115 developing, LeakMagic[1], which reported the following warning when
116 analyzing the v5.15 kernel release: 116 analyzing the v5.15 kernel release:
117 117
118 path/to/foo_bar.c:187: missing kfree() call 118 path/to/foo_bar.c:187: missing kfree() call?
119 119
120 Add the missing kfree() to the error path. N 120 Add the missing kfree() to the error path. No other references to
121 this memory exist outside the probe function 121 this memory exist outside the probe function, so this is the only
122 place it can be freed. 122 place it can be freed.
123 123
124 x86_64 and arm64 defconfig builds with CONFI 124 x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
125 11.2 show no new warnings, and LeakMagic no 125 11.2 show no new warnings, and LeakMagic no longer warns about this
126 code path. As we don't have a FooBar device 126 code path. As we don't have a FooBar device to test with, no runtime
127 testing was able to be performed. 127 testing was able to be performed.
128 128
129 [1] https://url/to/leakmagic/details 129 [1] https://url/to/leakmagic/details
130 130
131 Reported-by: Researcher <researcher@email> 131 Reported-by: Researcher <researcher@email>
132 Fixes: aaaabbbbccccdddd ("Introduce support 132 Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
133 Signed-off-by: Author <author@email> 133 Signed-off-by: Author <author@email>
134 Reviewed-by: Reviewer <reviewer@email> 134 Reviewed-by: Reviewer <reviewer@email>
135 135
136 Si usted es un colaborador por primera vez, se 136 Si usted es un colaborador por primera vez, se recomienda que el parche en
137 si sea examinado por otros en privado antes de 137 si sea examinado por otros en privado antes de ser publicado en listas
138 públicas. (Esto es necesario si se le ha dich 138 públicas. (Esto es necesario si se le ha dicho explícitamente que sus parches
139 necesitan una revisión interna más cuidadosa 139 necesitan una revisión interna más cuidadosa.) Se espera que estas personas
140 tengan su etiqueta “Reviewed-by” incluida 140 tengan su etiqueta “Reviewed-by” incluida en el parche resultante. Encontrar
141 otro desarrollador con conocimiento de las con 141 otro desarrollador con conocimiento de las contribuciones a Linux, especialmente
142 dentro de su propia organización, y tener su 142 dentro de su propia organización, y tener su ayuda con las revisiones antes de
143 enviarlas a las listas de correo publico tiend 143 enviarlas a las listas de correo publico tiende a mejorar significativamente la
144 calidad de los parches resultantes, y reduce a 144 calidad de los parches resultantes, y reduce así la carga de otros desarrolladores.
145 145
146 Si no se puede encontrar a nadie para revisar 146 Si no se puede encontrar a nadie para revisar internamente los parches y necesita
147 ayuda para encontrar a esa persona, o si tiene 147 ayuda para encontrar a esa persona, o si tiene alguna otra pregunta relacionada
148 con este documento y las expectativas de la co 148 con este documento y las expectativas de la comunidad de desarrolladores, por
149 favor contacte con la lista de correo privada 149 favor contacte con la lista de correo privada Technical Advisory Board:
150 <tech-board@groups.linuxfoundation.org>. 150 <tech-board@groups.linuxfoundation.org>.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.