Lines Matching refs:de

11 KVM se esfuerza por ser una comunidad acogedora; las contribuciones de los
13 se sienta intimidado por la extensión de este documento y las numerosas
16 seguir las directrices de KVM x86, sea receptivo a los comentarios, y
17 aprenda de los errores que cometa, será recibido con los brazos abiertos,
27 KVM x86 se encuentra actualmente en un período de transición de ser parte
28 del árbol principal de KVM, a ser "sólo otra rama de KVM". Como tal, KVM
29 x86 está dividido entre el árbol principal de KVM,
30 ``git.kernel.org/pub/scm/virt/kvm/kvm.git``, y un árbol específico de KVM
34 directamente al árbol principal de KVM, mientras que todo el desarrollo
35 para el siguiente ciclo se dirige a través del árbol de KVM x86. En el
36 improbable caso de que una corrección para el ciclo actual se dirija a
37 través del árbol KVM x86, se aplicará a la rama ``fixes`` antes de llegar
40 Tenga en cuenta que se espera que este periodo de transición dure bastante
45 El árbol de KVM x86 está organizado en múltiples ramas por temas. El
46 propósito de utilizar ramas temáticas más específicas es facilitar el
47 control de un área de desarrollo, y para limitar los daños colaterales de
49 de una rama temática no tiene impacto en los hashes SHA1 de otros commit
50 en en camino, y tener que rechazar una solicitud de pull debido a errores
54 ``next`` a través de un Cthulhu merge en función de las necesidades, es
58 Ciclo de Vida
61 mainline, suelen aplicarse directamente al árbol principal de KVM, es
62 decir, no pasan por el árbol x86 de KVM.
65 KVM x86. Se envían pull requests (de KVM x86 a KVM main) para cada rama
66 temática de KVM x86, normalmente la semana antes de que Linus abra la
67 ventana de fusión, por ejemplo, la semana siguiente a rc7 para las
69 el pull request principal de KVM enviado durante la ventana de fusión de
72 El árbol de KVM x86 no tiene su propia ventana de fusión oficial, pero hay
73 un cierre suave alrededor de rc5 para nuevas características, y un cierre
74 suave alrededor de rc6 para correcciones (para la próxima versión; fíjese
80 margen de maniobra en función del tamaño de la serie, los parches que están
83 lleven a través de un árbol que no sea KVM (la mayoría de las veces a
84 través del árbol de consejos) y/o que tengan otros acks/revisiones también
87 Tenga en cuenta que la mayor parte de la revisión se realiza entre rc1 y
89 para ponerse al día en otras tareas, es decir, la falta de envíos durante
93 tenga en cuenta el calendario del ciclo de publicación actual y tenga
96 lo posible, dentro de lo razonable, para asegurarse de que sus parches
98 compilación o fallan en las pruebas provocan el descontento de los
111 correcciones de errores urgentes, críticos y/o introducidos en la versión
115 necesidad de seleccionar una rama temática específica como base. Si hay
119 La única excepción al uso de ``kvm-x86/next`` como base es si un
121 modificaciones no triviales en el código común de KVM y/o tiene cambios más
122 que superficiales en el código de otras arquitecturas. Los parches/series
124 historia de KVM, por ejemplo, la versión candidata en la que se basa
125 ``kvm-x86 next``. Si no está seguro de si un parche/serie es realmente
131 Cuando se trata de estilo, nomenclatura, patrones, etc., la coherencia es
136 recomendaciones de los responsables del árbol de consejos
138 tocan tanto archivos x86 KVM como no KVM, es decir, llaman la atención de
139 los mantenedores de KVM *y* del árbol de consejos.
141 El uso del abeto inverso, también conocido como árbol de Navidad inverso o
142 árbol XMAS inverso, para las declaraciones de variables no es estrictamente
146 kernel-doc para las funciones. La gran mayoría de las funciones "públicas"
147 de KVM no son realmente públicas, ya que están destinadas únicamente al
148 consumo interno de KVM (hay planes para privatizar las cabeceras y
149 exportaciones de KVM para reforzar esto).
154 los comentarios para ofrecer una visión general de alto nivel del código
157 propio código es inescrutable, los comentarios no servirán de nada.
161 Gran parte de la base de código de KVM está directamente vinculada al
162 comportamiento de la arquitectura definido en El Manual de Desarrollo de
163 Software (SDM) de Intel y el Manual del Programador de Arquitectura (APM)
164 de AMD. El uso de "SDM de Intel" y "APM de AMD", o incluso sólo "SDM" o
176 comportamiento de la arquitectura, por lo que está implícito que el
177 comportamiento de KVM está emulando el comportamiento de SDM y/o APM. Tenga
178 en cuenta que hacer referencia al SDM/APM en los registros de cambios para
184 El formato de prefijo más recomendable es ``KVM: <topic>:``, donde
185 ``<topic>`` es uno de los siguientes::
197 **¡NO use x86/kvm!** ``x86/kvm`` se usa exclusivamente para cambios de
199 nombres de archivos o archivos completos como prefijo de asunto/shortlog.
202 temáticas se preocupan mucho más por los conflictos de código).
207 Escriba en mayúsculas la primera palabra de la descripción condensada del
210 	KVM: x86: Corregir una desviación de puntero nulo en function_xyz()
214 	kvm: x86: corregir una desviación de puntero nulo en function_xyz.
218 caso de duda, ``git log path/to/file`` debería proporcionar una pista
222 en la lista si desea proponer la introducción de un nuevo tema, es decir,
226 con una enmienda: no trate el límite de 70-75 caracteres como un límite
232 Registro de cambios
234 Y lo que es más importante, escriba los registros de cambios en modo
238 recomendación: comience con un breve resumen de los cambios reales y
240 conflicto directo con el enfoque preferido del árbol de sugerencias. Por
241 favor, siga el estilo preferido del árbol de sugerencias cuando envíe
245 KVM x86 prefiere indicar lo que hace un parche antes de entrar en detalles
248 información debe ser fácil de encontrar. Changelogs que entierran el "qué
249 está cambiando realmente" en una sola línea después de 3+ párrafos de fondo
255 serie de "git blame", los detalles de cada cambio a lo largo del camino son
258 de interés o no.
260 Otra ventaja de decir primero "qué cambia" es que casi siempre es posible
267 estricta de orden. Por ejemplo, tener que saltarse una frase para llegar al
273 Si un cambio corrige un error de KVM/kernel, añada una etiqueta Fixes:
282 explícita de los mantenedores (busque MANUALSEL).
286 Cuando se mencione una función en un comentario, registro de cambios o
293 Como mínimo, *todos* los parches de una serie deben construirse limpiamente
295 combinaciones posibles de Kconfigs no es factible, pero cuantas más mejor.
298 También es obligatorio ejecutar las autopruebas y las pruebas unitarias de
300 los cambios que tienen una probabilidad insignificante de afectar al
301 comportamiento en tiempo de ejecución, por ejemplo, parches que sólo
306 Para cambios que afecten al código de paginación en la sombra de KVM, es
308 afecten al código MMU común de KVM, se recomienda encarecidamente ejecutar
310 está modificando depende de y/o interactúa con un parámetro del módulo, es
313 Tenga en cuenta que las autopruebas de KVM y las pruebas de unidad de KVM
318 Los cambios que afecten a la documentación de texto reestructurado, es
319 decir, a los archivos .rst, deben generar htmldocs de forma limpia, es
322 Si no puede probar completamente un cambio, por ejemplo, por falta de
323 hardware, indique claramente qué nivel de pruebas ha podido realizar, por
324 ejemplo, en la carta de presentación.
329 de pruebas. Las pruebas específicas de KVM no son estrictamente necesarias,
330 por ejemplo, si la cobertura se proporciona mediante la ejecución de una
331 prueba de VM huésped suficientemente habilitada, o ejecutando una
332 autoprueba de kernel relacionada en una VM, pero en todos los casos se
333 prefieren las pruebas KVM dedicadas. Los casos de prueba negativos en
334 particular son obligatorios para la habilitación de nuevas características
335 de hardware, ya que los flujos de errores y excepciones rara vez se
339 soporte para un a través de KVM_GET_SUPPORTED_CPUID, es decir, para
344 características de hardware". Las nuevas funcionalidades que no puedan ser
345 validadas usando las pruebas existentes de KVM y/o las pruebas unitarias de
348 Es más que bienvenido el envío de nuevos desarrollos de características sin
350 etiquetados como RFC, y la carta de presentación debe indicar claramente
351 qué tipo de feedback se solicita/espera. No abuse del proceso de RFC; las
354 Corrección de Errores
356 Salvo en el caso de fallos "obvios" detectados por inspección, las
357 correcciones deben ir acompañadas de un reproductor del fallo corregido. En
358 muchos casos, el reproductor está implícito, por ejemplo, para errores de
359 compilación y fallos de prueba, pero debe quedar claro para lectores qué es
361 los errores detectados mediante cargas de trabajo/pruebas no públicas, pero
362 se recomienda encarecidamente que se faciliten pruebas de regresión para
365 En general, las pruebas de regresión son preferibles para cualquier fallo
366 que no sea trivial de encontrar. Por ejemplo, incluso si el error fue
367 encontrado originalmente por un fuzzer como syzkaller, una prueba de
369 condición de carrera de tipo uno en un millón.
371 Recuerde que los fallos de KVM rara vez son urgentes *y* no triviales de
372 reproducir. Pregúntate si un fallo es realmente el fin del mundo antes de
380 No haga referencia explícita a informes de errores, versiones anteriores de
383 número de versiones es alto, y ``In-Reply-To:`` es inútil para cualquiera
385 en el informe de error o si la lista de destinatarios cambia entre
388 Para enlazar con un informe de error, una versión anterior o cualquier cosa
389 de interés, utiliza enlaces lore. Para hacer referencia a versiones
390 anteriores, en general no incluya un Enlace: en el registro de cambios, ya
391 que no hay necesidad de registrar la historia en git, es decir, ponga el
392 enlace en la carta de presentación o en la sección que git ignora.
393 Proporcione un Enlace: formal para los informes de errores y/o discusiones
394 que condujeron al parche. El contexto de por qué se hizo un cambio es muy
399 Si utilizas la versión 2.9.0 o posterior de git (Googlers, ¡os incluimos a
405 upstream de una rama se establece en la rama temática base, por ejemplo,
407 con fines de copia de seguridad. Una solución "automática" alternativa es
408 derivar los nombres de tus ramas de desarrollo basándose en su KVM x86, e
410 luego escribir un pequeño wrapper para extraer ``pmu`` del nombre de la
414 Tests de Co-Publicación
416 Las autopruebas de KVM asociadas a cambios de KVM, por ejemplo, pruebas de
417 regresión para correcciones de errores, deben publicarse junto con los
418 cambios de KVM como una única serie. Se aplicarán las reglas estándar del
419 núcleo para la bisección, es decir, los cambios de KVM que provoquen fallos
420 en las pruebas se ordenarán después de las actualizaciones de las
421 autopruebas, y viceversa. Las pruebas que fallan debido a errores de KVM
422 deben ordenarse después de las correcciones de KVM.
426 se confunden cuando los parches de una serie se aplican en diferentes
427 árboles. Para vincular los parches de KVM-unit-tests a Parches KVM, primero
434 electrónico de notificación en respuesta a la publicación original (carta
435 de presentación para series de varios parches). La notificación incluirá el
436 árbol y la rama temática, junto con los SHA1 de los commits de los parches
439 Si se aplica un subconjunto de parches, se indicará claramente en la
444 Si por alguna razón se retira un parche después de haber sido aceptado
445 oficialmente, se enviará una respuesta al correo electrónico de
451 Los SHA1 no son 100% estables hasta que llegan al árbol de Linus. Un SHA1
453 ocurren cosas. En la mayoría de los casos, se proporcionará una
454 actualización del correo electrónico de notificación si se aplica un SHA1
456 ramas de KVM x86 necesitan ser rebasadas, no se darán notificaciones
462 host (kernel o espacio de usuario), o que pueden ser explotados por una VM
463 anidada a *su* host (L2 atacando a L1), son de particular interés para KVM.
465 fallo puede provocar una filtración de datos, etc.