Wie kann man einen potentiellen Patch auf dem Linux-Kernel einreichen?

StackOverflow https://stackoverflow.com/questions/434711

  •  10-07-2019
  •  | 
  •  

Frage

Wir haben einige Software, die auf einem bestimmtes Verhalten von einer anderen ( sehr häufig verwendeten) verließ Anwendung, die jetzt geändert hat, unsere aktuelle Implementierung praktikabel zu machen, aber weniger als optimal.

Wir glauben, dass diese Änderung eine Reihe von anderen Anwendungen beeinflusst haben könnte, vor allem in der Performance-Monitoring-Arena, und wir haben eine Lösung gefunden, dass wir eine ganze Reihe von anderen potenziellen Problemen zu verbessern glauben.

Leider, wobei die Lösung ist eine Kernel-Änderung (relativ einfache, aber hochschlag, wenn wir es stopfen oben), und wir haben keine Erfahrung Kernel-Patches für die Überprüfung in einreichen.

Hat jemand auf SO eingereicht tatsächlich ein Patch (während ich alle Antworten zu schätzen wissen würde ich vermuten, dass die besten, von denen kommen, die durch den Prozess gewesen, auch ohne Erfolg)? Haben Sie es akzeptiert hatte (was sind die Chancen, dass Alan Cox et al SO etwa auf hängt)?

Was ist der richtige Prozess zu folgen? Ich habe nicht die Absicht, eine E-Mail an Linus Absendung, da ich weiß, dass er einen Kader von Protektoren, die Sie durchlaufen soll, bevor du es ihm bekommt. Wie kann ich herausfinden, wer für einen bestimmten Abschnitt des Kernels verantwortlich ist.

Es kann sein, dass ich in der Annahme, jemand die Kernel Welt zu optimistisch zu sein nie beitragen gehört, aber ich würde mich interessieren, um herauszufinden.

EDIT mit mehr Details:

Die Änderung ist nicht wirklich für eine Leistung Fehler, aber eine Verbesserung (meiner Meinung nach) zu den Prozess-Accounting-Einträgen (derzeit) geschrieben, wenn ein Prozess beendet wird.

Websphere App Server (ah, IBM, segne ihre kleinen Herzen) hat sich verändert, was es tut; JVMs verwendet regelmäßig zu beenden, so dass ihre Einträge geschrieben wurden und wir, dass für Chargeback nutzen könnten. Jetzt lässt es JVMs um für Monate liegen, die Daten Bedeutung in angemessener Zeit nicht verfügbar ist, wenn wir nicht WAS zwingen, regelmäßig in. Irgendwie glaube ich nicht, IBM Software Group ihre Software :-) für uns beheben werden. Auf jeden Fall, ich glaube, es kann eine nützliche Funktion für andere langlebige Prozesse zu haben sein.

Derzeit Typ-3-Prozess Buchführung geschrieben werden, wenn ein Prozess beendet, was auf die wir suchen ein Mechanismus Typ-N Datensätze in regelmäßigen Abständen während ein Prozess noch aktiv geben die Zahlen seit dem letzten Schreiben (oder Prozess zu schreiben beginnen, wenn das ist das erste Mal). Chargeback oder Performance-Monitoring-Anwendungen können wählen, entweder den Typ-3-Datensatz (total unverändert) oder den Zwischentyp-N Datensätze verwenden. Die aktuelle Problemumgehung wir haben, ist / zu überwachen proc / PID / stat für bestimmte Prozesse, aber das ist eine schreckliche Flickschusterei, da es nicht gut mit dem realen Prozess-Accounting nicht integriert werden.

Es ist nicht oft sein muss (wir mit 24 Stunden glücklich sein würde), aber es kann eine Auswirkung auf die Leistung, da die Arbeit, die derzeit nur auf Prozess-Exit getan () wird gelegentlich auf Prozesskontextwechsel durchgeführt werden. Linus et al vielleicht nicht die Idee gefallen, da es sich um ein High-Impact-Bereich des Codes sein kann (auch überprüft, ob es sind 24 Stunden vergangen seit dem letzten Schreiben für sie zu langsam sein kann).

Dennoch vielen Dank für all die Antworten so weit, ich werde sehen, wie ich gehe. Gib mir ein paar Tage, und ich werde die beste Antwort akzeptieren.

War es hilfreich?

Lösung

Vor allem anderen: konzentriert sich auf die Leistung Bug-Report, und es richtig hinzubekommen (mit wiederholbaren Benchmarks) wird zumindest helfen Sie Menschen mit dem Problem zu stören zu bekommen. einreichen auch den Patch nach der Prüfung, aber passen Sie auf, Ihre große Patch den falschen Ansatz verwenden könnte, und dass sie vielleicht einen besseren schreiben. Oder dass einfach kann es groß sein, aber vielleicht müssen Korrekturen akzeptiert werden, dass auch bei Über-Jungs passiert. Und denken Sie nicht jemanden privat zu E-Mail, sondern beziehen sich auf LKML oder an den entsprechenden Subsystem ML.

Ich würde Ihnen vorschlagen, alle anderen Antworten zu lesen durch, und alle anwendbaren Material vor Kernel-Entwickler in Kontakt steht; und lesen Sie auch die Bibliographie von SubmittingPatches. Sie könnten hart, wenn man es falsch macht. Der kernelnewbies IRC-Chat ist ein guter Ort für Sie zu starten, weil sie sicher freundlich sind, auch wenn sie manchmal kann die Umgebung auch Neuling artig sein (nicht sicher, ich habe nicht so viel gewesen).

  

Es kann sein, dass ich in der Annahme, jemand die Kernel Welt zu optimistisch zu sein nie beitragen gehört, aber ich würde mich interessieren, um herauszufinden.

Es ist nicht zu optimistisch; an sich nicht zumindest. Abstrahieren von Ihnen (da ich nicht weiß, Ihre Fähigkeiten), was unwahrscheinlicher ist, dass Ihr Patch ohne Änderungen angenommen wird, oder dass es geschrieben nach den richtigen Fähigkeiten. Aber eigentlich, wenn Ihr Patch auf eine kleinere Gemeinschaft gerichtet ist, kann es viel einfacher.

Von jemandem mit etwas Erfahrung (das heißt mich), bevor Sie die Patch Vorlage unter Berücksichtigung beschreibt das Problem und warum wirkt es andere Anwendungen. Überlegungen wie „Das verbessert unsere Leistung“, vor allem wenn man (vage) als Lieferant qualifizieren, nicht Berufung auf Kernel-Entwickler haben wird.

Vor allem, lassen solche Aussagen:

  

Rendering unsere aktuelle Implementierung praktikabel, jedoch weniger als optimal.

da dies kaufen Sie ein „fix Code“ Empfehlung sofort von den meisten Lesern.

Wenn die Leistung einer bestehenden Anwendung (nicht von Ihnen geschrieben) betroffen ist, das ist etwas anderes. Zum Beispiel, wenn Linus prompt bezahlt Aufmerksamkeit in der Kernel-Performance für vermasselte Code Fixierung, denn dieser Code Teil make war, auch wenn er stolz auf den Code war er geschrieben hatte, und der Tatsache, dass er nicht zu tun brauchte dass eine exakte Lösung. Das heißt, Sie müssen eine Anwendung, die jeder kümmert sich um, oder eine Lösung ohne Nachteile. So Sachen wie:

  

Verhalten von einer anderen (sehr häufig verwendet) Anwendung

ist gut, solange Ihre Nutzung dieser Anwendung nicht unzumutbar ist.

Schließlich, wenn Sie auf den Quellcode beziehen, werden sie fragen, wahrscheinlich das Interesse Abschnitt zu sehen - man denke Probleme mit Ihrem Code lizenzieren, wenn sie vorhanden sind, und lösen jede von ihnen im Voraus, wenn Sie sie schnell beantworten wollen <. / p>

BTW, ist dies ein Teil wegen meiner Erfahrung gibt: https://www.ohloh.net/accounts/Blaisorblade

Wenn Sie möchten, können Sie mich kontaktieren Sie direkt mit einer vorgeschlagenen Mail zu helfen, und CC mich auf die Diskussion. Ich bin sehr beschäftigt, aber ich könnte etwas mehr Zeit finden: -).

Andere Tipps

Nun, Sie könnten versuchen, Dokumentation Lese / SubmittingPatches in dem Linux-Kernel-Quellbaum.

In einem großen Projekt, der beste Weg, einen Patch in den Hauptbaum zu erhalten, ist die Person zu wenden, der das besondere Stück Code wird beibehalten. Also, schauen Sie durch die Linux MAINTAINERS Datei , um zu sehen, die formal der Maintainer des Codes Sie‘ ve geändert und auch auf der Linux Kernel-SCM-Repository die Entwickler zu finden, die an diesem Code vor kurzem gearbeitet. Um Ihre Chancen des Patches zu erhöhen akzeptiert zu werden:

  • sicherstellen, dass Ihr Patch ist einfach zu verstehen und folgt vorhandenen Code und Dokumentationsstandards,
  • deutlich erklären, was Ihr Patch erreicht,
  • senden Sie Ihre Änderungen in einem geeigneten Format (die Ausgabe von diff-up für Linux)
  • stellen Sie sicher, kann der Patch sauber (und Werke) angewendet werden auf die neueste Software (Linux-Kernel) Version,
  • umfassen Testfälle, die sowohl das Problem zeigen Sie Adressierung und wie Ihr Patch löst es, und
  • beinhaltet nicht in Ihrem Code irrelevant (z Formatierung) ändert.

Ein kleines Update für einen bekannten Fehler ist wahrscheinlicher, in ein Projekt als große Änderungen am Code aufgenommen werden, die eine neue Funktion von Rand- oder fragwürdigem Nutzen einzuführen. In einigen Fällen ist es wert, zunächst einen Fehlerbericht über die Issue-Tracking-Datenbank Projektdatei, und dann einen Patch einreichen, die das spezifische Problem behebt. Um Enttäuschungen zu vermeiden, wenn Sie denken, eine große Veränderung zu machen, ist es besser, die Änderung und Ihre vorgeschlagene Umsetzung mit dem Betreuer vor Schreiben Sie den Code zu diskutieren.

Lesen Sie die Dokumentation / SubmittingPatches finden Sie im entsprechenden MAINTAINER, und was am wichtigsten ist, entdecken, wo die ganze Diskussion wirklich passiert. Es ist vielleicht nicht auf der Kernel-Mailingliste selbst, aber vielleicht auf einigen Subsystem ML.

Dann auf diese ML abonnieren, und Ihren Patch als RFC einreichen.

Ich weiß nicht, ob Ihre Patch-invasiv ist, aber versuchen Sie es in einer Warteschlange von logischen Wechseln zu spalten, jeder mit seiner eigenen Erklärung.

Ich habe Vorlage nicht versucht jeder Kernel-Patches selbst, und die docs in diese fehlen Bereich.

Aber diese Seite sieht aus wie es Sie in die richtige Richtung zeigen kann.

Auf der EDIT, könnte die Antwort als Beispiel Fall interessant sein. Ich denke, Ihre Anforderung völlig vernünftig ist, aber du hast recht, dass auch ein Test auf Kontextwechsel könnte zu teuer sein. Aber da der Kernel eine Timer-Implementierung hat, sehe ich nicht, warum es nicht verwendet werden kann, das zu vermeiden. Also, in der Tat, einen Antrag auf Erweiterung was darauf hindeutet, ist die sicherste Wette. Ich bin überrascht, dass Sie einen Fehlerbericht an Stelle eines Patches zu senden was darauf hindeutet, war so eine gute Passform. Sie können auch den Patch selbst ändern Timer selbst zu verwenden, wenn Sie es einreichen möchten, aber immer noch zur Diskussion bereit sein :-) Sie können auch hinzufügen, „wir eine lokale fix haben, aber es fügt einige Tests auf dem kontext Schalter schnell weg, das ist, warum der Patch als Referenz beigefügt ist, aber nicht angewendet werden sollte“. Drehen Sie Ihren eigenen Code, wenn es schlecht zu sein, ist bekannt, wird harte Kritik des Patches vermeiden.

Die Alternative besteht darin, einige Benchmarks zu laufen und beweisen es keine Auswirkungen, aber wenn Timer lebensfähig sind, dass Code wird sowieso abgelehnt werden, oder die Timer-Lösung selbst versuchen (etwas besser bestehen können). Finden Sie die Benchmarks sie für den Kernel-Scheduler verwenden; Blick auf den "letzten" Themen über den CFS Ingo (oder Kolivas'?) Patch und ihr Benchmarks nehmen.

Über Unterstützung, Kernel-Entwickler werden über „Websphere App Server“ von selbst sich nicht, wenn es unvernünftig Dinge tut, nicht einmal IBM finanzierte diejenigen. Aber mit meiner begrenzten Kenntnis der Situationen, Abschalten einer JVM regelmäßig keinen Sinn macht, scheint es nur einen Weg, um Papier über einen gewissen Speicherleck / Instabilität, so das aktuelle Verhalten muss unterstützt werden.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top