sp_SP/process/maintainer-kvm-x86.rst

1 .. include:: ../disclaimer-sp.rst
3 :Original: Documentation/process/maintainer-kvm-x86.rst
10 --------
15 principiantes en algún momento. Mientras haga un esfuerzo honesto por
21 -----
26 -------
27 KVM x86 se encuentra actualmente en un período de transición de ser parte
30 ``git.kernel.org/pub/scm/virt/kvm/kvm.git``, y un árbol específico de KVM
31 x86, ``github.com/kvm-x86/linux.git``.
41 tiempo, es decir, que será el statu quo en un futuro previsible.
47 control de un área de desarrollo, y para limitar los daños colaterales de
54 ``next`` a través de un Cthulhu merge en función de las necesidades, es
73 un cierre suave alrededor de rc5 para nuevas características, y un cierre
83 lleven a través de un árbol que no sea KVM (la mayoría de las veces a
102 -----------
114 Todo lo demás debería basarse en ``kvm-x86/next``, es decir, no hay
119 La única excepción al uso de ``kvm-x86/next`` como base es si un
120 parche/serie es una serie multi-arquitectura, es decir, tiene
123 multi-arquitectura deberían basarse en un punto común y estable en la
125 ``kvm-x86 next``. Si no está seguro de si un parche/serie es realmente
137 :ref:`maintainer-tip-coding-style`, ya que los parches/series a menudo
146 kernel-doc para las funciones. La gran mayoría de las funciones "públicas"
174 En general, no haga referencia explícita ni copie-pegue del SDM o APM en
187 - x86
188 - x86/mmu
189 - x86/pmu
190 - x86/xen
191 - autocomprobaciones
192 - SVM
193 - nSVM
194 - VMX
195 - nVMX
216 Si un parche afecta a varios temas, recorra el árbol conceptual hasta
221 De vez en cuando surgen nuevos temas, pero le rogamos que inicie un debate
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
238 recomendación: comience con un breve resumen de los cambios reales y
245 KVM x86 prefiere indicar lo que hace un parche antes de entrar en detalles
273 Si un cambio corrige un error de KVM/kernel, añada una etiqueta Fixes:
275 incluso si el cambio corrige un error en una versión anterior.
286 Cuando se mencione una función en un comentario, registro de cambios o
310 está modificando depende de y/o interactúa con un parámetro del módulo, es
314 tienen fallos conocidos. Si sospecha que un fallo no se debe a sus cambios,
322 Si no puede probar completamente un cambio, por ejemplo, por falta de
339 soporte para un a través de KVM_GET_SUPPORTED_CPUID, es decir, para
349 pruebas para obtener un feedback temprano, pero tales envíos deben ser
357 correcciones deben ir acompañadas de un reproductor del fallo corregido. En
367 encontrado originalmente por un fuzzer como syzkaller, una prueba de
369 condición de carrera de tipo uno en un millón.
372 reproducir. Pregúntate si un fallo es realmente el fin del mundo antes de
373 publicar una corrección sin un reproductor.
376 -----------
381 un parche/serie, etc. mediante cabeceras ``In-Reply-To:``. Usar
382 ``In-Reply-To:`` se convierte en un lío para grandes series y/o cuando el
383 número de versiones es alto, y ``In-Reply-To:`` es inútil para cualquiera
384 que no tenga el mensaje original, por ejemplo, si alguien no recibió un Cc
388 Para enlazar con un informe de error, una versión anterior o cualquier cosa
390 anteriores, en general no incluya un Enlace: en el registro de cambios, ya
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
400 todos!), utilice ``git format-patch`` con el indicador ``--base`` para
404 Tenga en cuenta que ``--base=auto`` funciona como se espera si y sólo si el
409 introdúzcalo en ``--base``. Por ejemplo, ``x86/pmu/mi_nombre_de_rama``, y
410 luego escribir un pequeño wrapper para extraer ``pmu`` del nombre de la
411 rama actual para obtener ``--base=x/pmu``, donde ``x`` es el nombre que su
414 Tests de Co-Publicación
424 KVM-unit-tests debería *siempre* publicarse por separado. Las herramientas,
425 por ejemplo b4 am, no saben que KVM-unit-tests es un repositorio separado y
427 árboles. Para vincular los parches de KVM-unit-tests a Parches KVM, primero
428 publique los cambios KVM y luego proporcione un enlace lore Link: al
429 parche/serie KVM en el parche(s) KVM-unit-tests.
433 Cuando se acepte oficialmente un parche/serie, se enviará un correo
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
451 Los SHA1 no son 100% estables hasta que llegan al árbol de Linus. Un SHA1
454 actualización del correo electrónico de notificación si se aplica un SHA1
464 Por favor, siga el protocolo para :ref:`securitybugs` si sospecha que un