¿Cómo se envía un posible parche al kernel de Linux?

Question

Tenemos algún software que se basó en cierto comportamiento de otra aplicación ( muy comúnmente utilizada) que ahora ha cambiado, haciendo que nuestra implementación actual sea viable, pero no óptima.

Creemos que este cambio puede haber afectado una serie de otras aplicaciones, particularmente en el ámbito de la supervisión del rendimiento, y hemos encontrado una solución que creemos que mejorará muchos otros problemas potenciales.

Desafortunadamente, dicha solución es un cambio de kernel (relativamente simple pero de alto impacto si lo rellenamos) y no tenemos experiencia en enviar parches de kernel para su revisión.

¿Alguien en SO envió realmente un parche (aunque agradecería todas las respuestas, sospecho que las mejores vendrán de aquellas que han pasado por el proceso, incluso sin éxito)? ¿Lo ha aceptado (¿cuáles son las posibilidades de que Alan Cox et al se cuelguen de SO)?

¿Cuál es el proceso correcto a seguir? No tengo intención de enviar un correo electrónico a Linus ya que sé que tiene un grupo de protectores por los que se supone que debes pasar antes de que llegue a él. ¿Cómo puedo averiguar quién es responsable de una sección particular del núcleo?

Puede ser que estoy siendo demasiado optimista al pensar que alguien de quien el mundo del kernel nunca ha oído hablar puede contribuir, pero me interesaría averiguarlo.

---

EDITAR con más detalles:

El cambio no es en realidad un error de rendimiento, sino una mejora (en mi opinión) de las entradas de contabilidad de proceso (actualmente) escritas cuando finaliza un proceso.

El servidor de aplicaciones Websphere (ah, IBM, bendiga sus pequeños corazones) ha cambiado lo que hace; Las JVM solían salir regularmente para que sus entradas se escribieran y podríamos usar eso para contracargos. Ahora deja a las JVM por meses, lo que significa que los datos no están disponibles de manera oportuna a menos que obliguemos a WAS a bajar regularmente. De alguna manera, no creo que el Grupo de Software de IBM arregle su software para nosotros :-). En cualquier caso, creo que puede ser una característica útil para otros procesos de larga duración.

Actualmente, los registros de contabilidad de procesos de tipo 3 se escriben cuando sale un proceso, lo que estamos viendo es un mecanismo para escribir registros de tipo N periódicamente mientras un proceso todavía está activo, dando las cifras desde la última escritura (o inicio del proceso si Esta es la primera vez). Las aplicaciones de devolución de cargo o de supervisión del rendimiento podrían optar por utilizar los registros de tipo 3 (totalmente sin cambios) o los registros de tipo N provisionales. La solución actual que tenemos es monitorear / proc / PID / stat para procesos específicos, pero es un error horrible ya que no se integra bien con la contabilidad de procesos reales.

No es necesario que sea frecuente (estaríamos contentos con 24 horas), pero puede haber un impacto en el rendimiento ya que el trabajo que actualmente se realiza solo en la salida del proceso () tendrá que hacerse ocasionalmente en el cambio de contexto del proceso. Puede que a Linus y otros no les guste esa idea, ya que puede ser un área de alto impacto del código (incluso comprobando si han pasado 24 horas desde que la última escritura puede ser demasiado lenta para ellos).

Aún así, gracias por todas las respuestas hasta ahora, veré cómo me va. Dame un par de días y aceptaré la mejor respuesta.

Answer 1

Antes que nada: concentrarse en el informe de errores de rendimiento y hacerlo bien (con puntos de referencia repetibles) al menos lo ayudará a hacer que las personas se molesten con el problema. También envíe el parche después de probarlo, pero tenga en cuenta que su gran parche podría usar un enfoque incorrecto y que podrían escribir uno mejor. O eso simplemente puede ser genial, pero podría necesitar soluciones para ser aceptado, lo que incluso sucede con uber-guys. Y no piense en enviar un correo electrónico a alguien en privado, sino que consulte LKML o el subsistema ML apropiado.

Le sugiero que lea todas las demás respuestas y todo el material aplicable, antes de contactar a los desarrolladores del kernel; y lea la bibliografía de SubmittingPatches también. Pueden ser duros si lo haces mal. El chat IRC de kernelnewbies es un buen lugar para comenzar, ya que es seguro que es acogedor, incluso si a veces el ambiente puede ser demasiado novato (no estoy seguro, no he estado allí tanto).

  

Puede ser que estoy siendo demasiado optimista al pensar que alguien de quien el mundo del kernel nunca ha oído hablar puede contribuir, pero me interesaría averiguarlo.

No es demasiado optimista; no en sí mismo al menos. Resumiendo de usted (ya que no conozco sus habilidades), lo que es más improbable es que su parche sea aceptado sin modificaciones, o que esté escrito de acuerdo con las habilidades correctas. Pero en realidad, si su parche está dirigido a una comunidad más pequeña, puede ser mucho más fácil.

De alguien con algo de experiencia (es decir, yo), antes de considerar el envío del parche, describa el problema y por qué afecta a otras aplicaciones. Consideraciones como "esto mejora nuestro rendimiento", especialmente si usted califica (vagamente) como proveedor, no tendrá atractivo para los desarrolladores del kernel.

Especialmente, omita tales declaraciones:

  

haciendo que nuestra implementación actual sea viable, pero menos que óptima.

porque esto le comprará un " arregle su código " recomendación inmediata de la mayoría de los lectores.

Si el rendimiento de una aplicación existente (no escrita por usted) se ve afectado, eso es diferente. Por ejemplo, una vez que Linus prestó atención de inmediato a la fijación del rendimiento del kernel para el código jodido, porque ese código era parte de make, incluso si estaba orgulloso del código que había escrito y del hecho de que no necesitaba hacerlo. Esa solución exacta. Es decir, necesita una aplicación que le interese a todos, o una solución sin inconvenientes. Entonces, cosas como:

  

comportamiento de otra aplicación (muy utilizada)

es bueno, siempre y cuando su uso de esa aplicación no se considere irrazonable.

Finalmente, si hace referencia al código fuente, es probable que le pidan ver la sección interesada: piense en licenciar los problemas con su código, si existen, y resuelva cualquiera de ellos de antemano si desea responderlos rápidamente.

Por cierto, esta es una cuenta parcial de mi experiencia allí: https://www.ohloh.net/accounts/Blaisorblade

Si lo desea, puede ponerse en contacto conmigo para ayudarlo directamente con un correo propuesto y enviarme un correo electrónico sobre la discusión. Estoy bastante ocupado, pero podría encontrar más tiempo :-).

Answer 2

Bueno, podría intentar leer Documentation / SubmittingPatches en el árbol de fuentes del kernel de Linux.

Answer 3

En un proyecto grande, la mejor manera de obtener un parche en el árbol principal es contactar a la persona que mantiene el código en particular. Por lo tanto, mire a través del archivo Linux MAINTAINERS para ver quién es formalmente el mantenedor del código que usted ' he cambiado y también en Linux kernel SCM repositorio para ubicar a los desarrolladores que recientemente trabajaron en ese código. Para aumentar sus posibilidades de que el parche sea aceptado:

• asegúrese de que su parche sea fácil de entender y siga los códigos y estándares de documentación existentes,
• explique claramente lo que logra su parche,
• envíe sus cambios en un formato apropiado (la salida de diff -up para Linux),
• asegúrese de que el parche se puede aplicar limpiamente (y funciona) en la última versión del software (kernel de Linux),
• incluya casos de prueba que demuestren el problema que está abordando y cómo lo resuelve su parche, y
• no incluya en su código cambios irrelevantes (por ejemplo, formato).

Es más probable que una pequeña solución para un error conocido se incorpore a un proyecto que los grandes cambios de código que introducen una nueva característica de utilidad marginal o dudosa. En algunos casos, vale la pena presentar primero un informe de error a través de la base de datos de seguimiento de problemas del proyecto y luego enviar un parche que aborde el problema específico. Para evitar decepciones, si está pensando en hacer un gran cambio, es mejor discutir el cambio y su implementación propuesta con el responsable antes de escribir el código.

Answer 4

Lea la documentación / SubmittingPatches, encuentre el MANTENEDOR apropiado y, lo más importante, descubra dónde está realmente toda la discusión. Puede que no esté en la lista de correo del kernel en sí, pero tal vez en algún subsistema ML.

Luego suscríbase a este ML y envíe su parche como RFC.

No sé si su parche es invasivo, pero intente dividirlo en una cola de cambio lógico, cada uno con su propia explicación.

Answer 5

No he intentado enviar parches de kernel yo mismo, y los faltan documentos en este zona.

Pero esta página parece que puede orientarlo en la dirección correcta.

Answer 6

En EDITAR, la respuesta puede ser interesante como un caso de ejemplo. Supongo que su requisito es totalmente razonable, pero tiene razón en que incluso una prueba de cambio de contexto podría ser demasiado costosa. Pero como el núcleo tiene una implementación de temporizador, no veo por qué no se puede usar para evitar eso. Entonces, de hecho, sugerir una solicitud de mejora es la apuesta más segura. Me sorprende que sugerir enviar un informe de error en lugar de un parche fuera tan adecuado. También puede modificar el parche usted mismo para usar temporizadores si desea enviarlo, pero aún así estar listo para la discusión :-) Incluso puede agregar "tenemos una solución local, pero agrega algunas pruebas en la ruta rápida de cambio de contexto, es por eso que el parche se adjunta como referencia, pero no debe aplicarse". Si rechaza su propio código, si se sabe que es malo, evitará revisiones severas del parche.

La alternativa es ejecutar algunos puntos de referencia y demostrar que no hay impacto, pero si los temporizadores son viables, ese código será rechazado de todos modos, o probar la solución del temporizador usted mismo (algo mejor puede existir). Encuentre los puntos de referencia que usan para el planificador del núcleo; mira el " reciente " subprocesos sobre el parche CFS Ingo (¿o Kolivas?) y toman sus puntos de referencia.

Sobre el soporte, a los desarrolladores de kernel no les importará " Servidor de aplicaciones Websphere " por sí mismo, si hace cosas irracionales, ni siquiera las financiadas por IBM. Pero con mi conocimiento limitado de las situaciones, cerrar una JVM periódicamente no tiene sentido, parece solo una forma de ocultar alguna pérdida / inestabilidad de memoria, por lo que el comportamiento actual debe ser compatible.