1 .. SPDX-License-Identifier: GPL-2.0
2
3 :Original: :ref:`Documentation/process/researc
4 :Translator: Avadhut Naik <avadhut.naik@amd.com
5
6 Directrices para Investigadores
7 ++++++++++++++++++++++++++++++++
8
9 La comunidad del kernel de Linux da la bienven
10 transparente sobre el kernel de Linux, las act
11 en su producción, otros subproductos de su de
12 beneficia mucho de este tipo de investigación
13 aspectos de Linux son impulsados por investiga
14
15 La comunidad agradece mucho si los investigado
16 los hallazgos preliminares antes de hacer púb
17 especialmente si tal investigación involucra
18 temprano ayuda a mejorar la calidad de investi
19 de Linux para mejorar a partir de ella. En cua
20 compartir copias de acceso abierto de la inves
21 la comunidad.
22
23 Este documento busca clarificar lo que la comu
24 considera practicas aceptables y no aceptables
25 investigación de este tipo. Por lo menos, dic
26 actividades afines deben seguir las reglas est
27 investigación. Para más información sobre l
28 en general, ética en la tecnología y la inve
29 de desarrolladores en particular, ver:
30
31
32 * `Historia de la Ética en la Investigación
33 * `Ética de la IEEE <https://www.ieee.org/abo
34 * `Perspectivas de Desarrolladores e Investiga
35
36 La comunidad del kernel de Linux espera que to
37 el proyecto están participando en buena fe pa
38 investigación sobre cualquier artefacto dispo
39 pero no limitado a código fuente) producido p
40 de Linux es bienvenida, aunque la investigaci
41 debe ser claramente opcional.
42
43 La investigación pasiva que se basa completam
44 públicamente, incluidas las publicaciones en
45 las contribuciones a los repositorios público
46 Aunque, como con cualquier investigación, tod
47 estándar.
48
49 La investigación activa sobre el comportamien
50 sin embargo, debe hacerse con el acuerdo expl
51 completa a los desarrolladores individuales in
52 interactuar / experimentar con los desarrollad
53 esto también es ética de investigación est
54
55 Para ayudar a aclarar: enviar parches a los de
56 con ellos, pero ya han dado su consentimiento
57 en buena fe. No se ha dado consentimiento para
58 defectuosos / vulnerables o contribuir con la
59 discusiones. Dicha comunicación puede ser per
60 ejemplo, agotar el tiempo, el esfuerzo, y la m
61 proyecto al erosionar la confianza de toda la
62 el colaborador (y la organización del colabor
63 los esfuerzos para proporcionar reacciones con
64 y poniendo a los usuarios finales en riesgo de
65
66 La participación en el desarrollo de Linux en
67 investigadores, como con cualquiera, es bienve
68 investigación del código de Linux es una pr
69 cuando se trata de desarrollar o ejecutar herr
70 producen resultados procesables.
71
72 Cuando se interactúa con la comunidad de desa
73 parche ha sido tradicionalmente la mejor maner
74 Linux ya tiene muchos errores conocidos – lo
75 tener soluciones verificadas. Antes de contrib
76 la documentación adecuada.
77
78 * Documentation/process/development-process.rs
79 * Documentation/process/submitting-patches.rst
80 * Documentation/admin-guide/reporting-issues.r
81 * Documentation/process/security-bugs.rst
82
83 Entonces envíe un parche (incluyendo un regis
84 todos los detalles enumerados abajo) y haga un
85 comentario de otros desarrolladores.
86
87 * ¿Cuál es el problema específico que se ha
88 * ¿Como podría llegar al problema en un sist
89 * ¿Qué efecto tendría encontrar el problema
90 * ¿Como se encontró el problema? Incluya esp
91 cualquier prueba, programas de análisis est
92 otra herramienta o método utilizado para re
93 * ¿En qué versión de Linux se encontró el
94 versión más reciente o una rama reciente d
95 Documentation/process/howto.rst).
96 * ¿Que se cambió para solucionar el problema
97 * ¿Como se probó el cambio para la complicac
98 * ¿Qué confirmación previa corrige este cam
99 etiqueta como se describe en la documentaci
100 * ¿Quién más ha revisado este parche? Esto
101 etiqueta; Vea abajo.
102
103 Por ejemplo (en inglés, pues es en las listas
104
105 From: Author <author@email>
106 Subject: [PATCH] drivers/foo_bar: Add missin
107
108 The error path in foo_bar driver does not co
109 struct foo_bar_info. This can happen if the
110 rejects the initialization packets sent duri
111 would result in a 64 byte slab memory leak o
112 wasting memory resources over time.
113
114 This flaw was found using an experimental st
115 developing, LeakMagic[1], which reported the
116 analyzing the v5.15 kernel release:
117
118 path/to/foo_bar.c:187: missing kfree() call
119
120 Add the missing kfree() to the error path. N
121 this memory exist outside the probe function
122 place it can be freed.
123
124 x86_64 and arm64 defconfig builds with CONFI
125 11.2 show no new warnings, and LeakMagic no
126 code path. As we don't have a FooBar device
127 testing was able to be performed.
128
129 [1] https://url/to/leakmagic/details
130
131 Reported-by: Researcher <researcher@email>
132 Fixes: aaaabbbbccccdddd ("Introduce support
133 Signed-off-by: Author <author@email>
134 Reviewed-by: Reviewer <reviewer@email>
135
136 Si usted es un colaborador por primera vez, se
137 si sea examinado por otros en privado antes de
138 públicas. (Esto es necesario si se le ha dich
139 necesitan una revisión interna más cuidadosa
140 tengan su etiqueta “Reviewed-by” incluida
141 otro desarrollador con conocimiento de las con
142 dentro de su propia organización, y tener su
143 enviarlas a las listas de correo publico tiend
144 calidad de los parches resultantes, y reduce a
145
146 Si no se puede encontrar a nadie para revisar
147 ayuda para encontrar a esa persona, o si tiene
148 con este documento y las expectativas de la co
149 favor contacte con la lista de correo privada
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.