Comment peut-on soumettre un correctif potentiel au noyau Linux?

Question

Certains logiciels reposent sur certains comportements d'une autre application ( très couramment utilisée) qui a maintenant changé, ce qui rend notre implémentation actuelle réalisable, mais pas optimale.

Nous pensons que ce changement a pu affecter plusieurs autres applications, en particulier dans le domaine de la surveillance des performances, et nous avons trouvé une solution qui, à notre avis, permettra d’améliorer de nombreux autres problèmes potentiels.

Malheureusement, cette solution est un changement de noyau (relativement simple mais qui a un impact important si nous la gênons) et nous n’avons aucune expérience dans la soumission de correctifs de noyau pour révision.

Quelqu'un sur SO a-t-il réellement soumis un correctif (bien que j'apprécie toutes les réponses, je suppose que les meilleures viendront de celles qui ont suivi le processus, même sans succès)? L'avez-vous accepté (quelles sont les chances qu'Alan Cox et autres traînent sous SO)?

Quel est le bon processus à suivre? Je n'ai pas l'intention d'envoyer un courrier électronique à Linus, car je sais qu'il dispose d'un groupe de protecteurs que vous êtes censé subir avant de le recevoir. Comment savoir qui est responsable d’une section particulière du noyau?

Il se peut que je sois trop optimiste en pensant que quelqu'un dont le monde du noyau n'a jamais entendu parler peut contribuer, mais je serais intéressé de le savoir.

EDIT avec plus de détails:

La modification ne concerne pas réellement un bogue de performance, mais une amélioration (à mon avis) des écritures comptables de processus (actuellement) écrites à la fin d'un processus.

Websphere App Server (ah, IBM, bénissez leurs petits cœurs) a changé son comportement; Les machines virtuelles avaient l'habitude de sortir régulièrement afin que leurs entrées soient écrites et que nous puissions utiliser cela pour la rétrofacturation. Maintenant, les machines virtuelles sont laissées traîner pendant des mois, ce qui signifie que les données ne sont pas disponibles à temps, sauf si nous forcons régulièrement WAS à se déconnecter. D'une manière ou d'une autre, je ne pense pas que le groupe de logiciels d'IBM va réparer leur logiciel pour nous :-). Dans tous les cas, je pense que cela peut être utile pour d’autres processus de longue durée.

Actuellement, les écritures comptables de processus de type 3 sont écrites à la sortie d’un processus. Nous examinons un mécanisme permettant d’écrire périodiquement des enregistrements de type N pendant qu’un processus est toujours actif et donne les chiffres depuis la dernière écriture (ou le début du processus si c'est la première fois). Les applications de rétrofacturation ou de surveillance des performances peuvent choisir d’utiliser les enregistrements de type 3 (totalement inchangés) ou les enregistrements de type N provisoires. La solution de contournement actuelle consiste à surveiller / proc / PID / stat pour des processus spécifiques, mais c’est un horrible kludge car il ne s’intègre pas bien à la comptabilité des processus réels.

Cela ne doit pas être souvent (nous serions heureux avec 24 heures) mais il peut y avoir un impact sur les performances puisque le travail actuellement effectué uniquement sur process exit () devra être effectué occasionnellement sur le changement de contexte de processus. Linus et ses collègues pourraient ne pas aimer cette idée, car il s’agit peut-être d’une zone du code très impactante (même s’il a été 24 heures, la dernière écriture risque d’être trop lente pour eux).

Néanmoins, merci pour toutes les réponses jusqu’à présent, je vais voir comment je vais. Donnez-moi quelques jours et j'accepterai la meilleure réponse.

Answer 1

Avant toute chose: se concentrer sur le rapport de bogue de performance et le faire correctement (avec des repères répétables) vous aidera au moins à amener les gens à se préoccuper du problème. Soumettez également le correctif après l'avoir testé, mais sachez que votre excellent correctif pourrait utiliser une mauvaise approche et qu'ils pourraient en écrire une meilleure. Ou simplement que cela peut être génial, mais que des correctifs sont nécessaires pour être accepté, ce qui arrive même avec les super-gars. Et ne pensez pas envoyer un e-mail à quelqu'un en privé, mais consultez LKML ou le sous-système approprié ML.

Je vous suggérerais de lire toutes les autres réponses et tous les documents pertinents avant de contacter les développeurs du noyau. et lisez également la bibliographie de SubmittingPatches. Ils pourraient être durs si vous le faites mal. Le chat IRC de kernelnewbies est un bon endroit pour commencer, car il est sûr d’être accueillant, même si parfois l’environnement peut sembler un peu trop novice (incertain, je n’y suis jamais allé autant).

  

Il se peut que je sois trop optimiste en pensant que quelqu'un dont le monde du noyau n'a jamais entendu parler peut contribuer, mais je serais intéressé de le savoir.

Ce n'est pas trop optimiste; pas en soi du moins. En vous abstenant (étant donné que je ne connais pas vos compétences), il est plus improbable que votre correctif soit accepté sans modifications ou qu'il soit écrit selon les bonnes compétences. Mais en réalité, si votre correctif s'adresse à une communauté plus petite, cela sera peut-être beaucoup plus facile.

De la part de quelqu'un qui a une certaine expérience (c'est-à-dire moi), avant d'examiner la soumission du correctif, décrivez le problème et expliquez pourquoi il affecte d'autres applications. Des considérations telles que "cela améliore nos performances", en particulier si vous vous qualifiez (vaguement) en tant que vendeur, n'auront aucun attrait pour les développeurs du noyau.

Surtout, omettez ces déclarations:

  

rendant notre implémentation actuelle réalisable, mais pas optimale.

car cela vous achètera un " réparer votre code " recommandation immédiatement par la plupart des lecteurs.

Si les performances d'une application existante (non écrite par vous) sont affectées, c'est différent. Par exemple, une fois que Linus a immédiatement prêté attention à la correction des performances du noyau pour le code vissé, parce que ce code faisait partie de la marque, même s'il était fier du code qu'il avait écrit et du fait qu'il n'avait pas besoin de le faire. cette solution exacte. C'est-à-dire que vous avez besoin d'une application qui intéresse tout le monde ou d'une solution sans inconvénients. Donc, des trucs comme:

  

comportement d'une autre application (très utilisée)

est bon, tant que votre utilisation de cette application n'est pas jugée déraisonnable.

Enfin, si vous vous référez au code source, ils vous demanderont probablement de consulter la section concernée - pensez aux problèmes de licence avec votre code, s’ils existent, et résolvez-en au préalable si vous souhaitez y répondre rapidement.

Btw, voici un compte-rendu partiel de mon expérience: https://www.ohloh.net/accounts/Blaisorblade

Si vous le souhaitez, vous pouvez me contacter pour vous aider directement avec un courrier proposé et me contacter pour la discussion. Je suis assez occupé, mais je pourrais trouver plus de temps: -).

Answer 2

Eh bien, vous pouvez essayer de lire Documentation / SubmittingPatches dans l'arborescence des sources du noyau Linux.

Answer 3

Dans un grand projet, le meilleur moyen d’obtenir un correctif dans l’arborescence principale est de contacter la personne qui gère le code particulier. Alors, consultez le fichier Linux MAINTAINERS pour voir qui est officiellement le responsable du code Nous avons également changé et à la Linux référentiel SCM du noyau pour localiser les développeurs qui ont récemment travaillé sur ce code. Pour augmenter vos chances que le correctif soit accepté:

• assurez-vous que votre correctif est facile à comprendre et respecte les normes de code et de documentation existantes,
• expliquez clairement les résultats de votre correctif,
• soumettez vos modifications dans un format approprié (la sortie de diff -up pour Linux),
• assurez-vous que le correctif peut être appliqué proprement (et fonctionne) sur la dernière version du logiciel (noyau Linux),
• incluez des scénarios de test qui illustrent à la fois le problème que vous résolvez et la façon dont votre correctif le résout, et
• n'incluez pas dans votre code les modifications non pertinentes (formatage, par exemple).

Un petit correctif pour un bogue connu est plus susceptible d’être incorporé dans un projet que des modifications de code importantes qui introduisent une nouvelle fonctionnalité d’utilité marginale ou douteuse. Dans certains cas, il est utile de commencer par créer un rapport de bogue via la base de données de suivi des problèmes du projet, puis de soumettre un correctif qui résout le problème spécifique. Pour éviter toute déception, si vous envisagez de réaliser un changement important, il est préférable de discuter du changement et de la mise en œuvre proposée avec le responsable avant d'écrire le code.

Answer 4

Lisez les dossiers de documentation / soumission, trouvez le MAINTAINER approprié et, surtout, découvrez où se déroule la vraiment discussion. Cela ne se trouve peut-être pas dans la liste de diffusion du noyau, mais peut-être dans certains sous-systèmes ML.

Ensuite, abonnez-vous à cette ML et soumettez votre correctif en tant que RFC.

Je ne sais pas si votre correctif est invasif, mais essayez de le diviser en une file d'attente de modifications logiques, chacune avec sa propre explication.

Answer 5

Je n'ai pas essayé de soumettre moi-même de correctifs du noyau, et les docs manquent dans ce dossier. surface.

Mais cette page semble pouvoir vous orienter dans la bonne direction.

Answer 6

Sur EDIT, la réponse pourrait être intéressante à titre d'exemple. Je suppose que votre exigence est tout à fait raisonnable, mais vous avez raison de dire que même un test de changement de contexte peut être trop coûteux. Mais comme le noyau a une implémentation de minuterie, je ne vois pas pourquoi cela ne pourrait pas être utilisé pour éviter cela. Donc, en effet, suggérer une demande d'amélioration est le pari le plus sûr. Je suis surpris que suggérer d'envoyer un rapport de bogue au lieu d'un correctif me convienne si bien. Vous pouvez également modifier le correctif vous-même pour utiliser les minuteries vous-même si vous souhaitez le soumettre, tout en restant prêt pour la discussion :-) Vous pouvez même ajouter "nous avons un correctif local, mais il ajoute des tests sur le raccourci de changement de contexte, c'est pourquoi le correctif est joint à titre de référence mais ne doit pas être appliqué". Refuser votre propre code, s’il est connu pour être mauvais, évitera les critiques sévères du correctif.

L’alternative consiste à exécuter des tests de performance et à prouver qu’il n’ya pas d’impact, mais si les minuteries sont viables, ce code sera quand même rejeté, ou bien essayez vous-même la solution de minuterie (il peut exister quelque chose de mieux). Recherchez les repères qu’ils utilisent pour le planificateur de noyau; regardez le " récent " discussions sur le correctif de CFS Ingo (ou de Kolivas?) et prennent leurs repères.

À propos du support, les développeurs du noyau ne s’inquiètent pas de & Web; Websphere App Server " en soi, si elle fait des choses déraisonnables, pas même celles financées par IBM. Mais avec ma connaissance limitée des situations, arrêter périodiquement une machine virtuelle Java n’a pas de sens, cela semble juste un moyen d’écrire sur une fuite / instabilité de mémoire, le comportement actuel doit donc être pris en charge.