Come si fa a inviare una potenziale patch al kernel Linux?

Question

Abbiamo alcuni software che si basavano su un determinato comportamento di un'altra applicazione ( molto usata comunemente usata) che ora è cambiata, rendendo la nostra attuale implementazione praticabile, ma meno che ottimale.

Riteniamo che questa modifica possa aver influito su numerose altre applicazioni, in particolare nell'ambito del monitoraggio delle prestazioni, e abbiamo trovato una soluzione che riteniamo possa migliorare una serie di altri potenziali problemi.

Sfortunatamente, detta soluzione è un cambiamento del kernel (relativamente semplice ma di grande impatto se lo riempiamo) e non abbiamo esperienza nell'inviare le patch del kernel per la revisione.

Qualcuno su SO ha effettivamente inviato una patch (anche se apprezzerei tutte le risposte, sospetto che le migliori verranno da quelle che hanno superato il processo, anche senza successo)? L'hai fatto accettare (quali sono le possibilità che Alan Cox et al. Appaiano su SO)?

Qual è il processo corretto da seguire? Non ho intenzione di inviare un'e-mail a Linus poiché so che ha un gruppo di protettori che dovresti passare prima che arrivi a lui. Come faccio a sapere chi è responsabile di una particolare sezione del kernel.

Può darsi che io sia troppo ottimista nel pensare che qualcuno di cui il mondo del kernel non ha mai sentito parlare possa contribuire, ma sarei interessato a scoprirlo.

---

MODIFICA con maggiori dettagli:

La modifica non riguarda in realtà un bug delle prestazioni, ma un miglioramento (a mio avviso) delle voci di contabilità del processo (attualmente) scritte al termine di un processo.

Websphere App Server (ah, IBM, benedici i loro cuoricini) ha cambiato ciò che fa; Le JVM erano solite uscire regolarmente in modo che le loro voci fossero scritte e potessimo utilizzarle per lo storno di addebito. Ora lascia le JVM in giro per mesi, il che significa che i dati non sono disponibili in modo tempestivo a meno che non forziamo regolarmente la WAS. In qualche modo non credo che il Software Group di IBM risolverà il loro software per noi :-). In ogni caso, credo che potrebbe essere una caratteristica utile da avere per altri processi di lunga durata.

Attualmente i record di contabilità del processo di tipo 3 vengono scritti all'uscita da un processo, quello che stiamo osservando è un meccanismo per scrivere periodicamente i record di tipo N mentre un processo è ancora attivo fornendo le cifre dall'ultima scrittura (o l'avvio del processo se questa è la prima volta). Le applicazioni di chargeback o di monitoraggio delle prestazioni potrebbero scegliere di utilizzare i record di tipo 3 (totalmente invariati) o i record di tipo N provvisori. L'attuale soluzione alternativa che abbiamo è monitorare / proc / PID / stat per processi specifici, ma questo è un orribile kludge poiché non si integra bene con la contabilità dei processi reali.

Non dovrebbe essere frequente (saremo contenti di 24 ore) ma potrebbe esserci un impatto sulle prestazioni poiché il lavoro attualmente svolto solo all'uscita del processo () dovrà essere eseguito occasionalmente sul cambio di contesto del processo. A Linus et al potrebbe non piacere quell'idea poiché potrebbe essere un'area di grande impatto del codice (anche controllando se ci sono state 24 ore dall'ultima scrittura potrebbe essere troppo lento per loro).

Comunque, grazie per tutte le risposte finora, vedrò come vado. Dammi un paio di giorni e accetterò la risposta migliore.

Answer 1

Prima di ogni altra cosa: concentrarsi sulla segnalazione dei bug delle prestazioni e farlo correttamente (con benchmark ripetibili) ti aiuterà almeno a indurre le persone a preoccuparsi del problema. Invia anche la patch dopo averla testata, ma fai attenzione che la tua grande patch potrebbe usare un approccio sbagliato e che potrebbe scriverne una migliore. O semplicemente potrebbe essere fantastico, ma potrebbe essere necessario correggere per essere accettato, ciò accade anche con i super-ragazzi. E non pensare di inviare un'email a qualcuno in privato, ma fai riferimento a LKML o al sottosistema ML appropriato.

Ti consiglierei di leggere tutte le altre risposte, e tutto il materiale applicabile, prima di contattare gli sviluppatori del kernel; e leggi anche la bibliografia di SubmittingPatches. Potrebbero essere difficili se lo fai in modo sbagliato. La chat IRC del kernelnewbies è un buon punto di partenza, perché sono sicuramente accoglienti, anche se a volte l'ambiente può essere troppo simile ai principianti (non sono sicuro, non ci sono stato così tanto).

  

Può darsi che io sia troppo ottimista nel pensare che qualcuno di cui il mondo del kernel non ha mai sentito parlare possa contribuire, ma sarei interessato a scoprirlo.

Non è eccessivamente ottimista; almeno in sé. Sottraendo da te (poiché non conosco le tue abilità), ciò che è più improbabile è che la tua patch sarà accettata senza modifiche o che sia scritta secondo le giuste abilità. Ma in realtà, se la tua patch è indirizzata a una comunità più piccola, potrebbe essere molto più semplice.

Da qualcuno con una certa esperienza (cioè io), prima di considerare l'invio della patch, descrivi il problema e perché influisce su altre applicazioni. Considerazioni come "questo migliora le nostre prestazioni", specialmente se ti qualifichi (vagamente) come un fornitore, non farà appello agli sviluppatori del kernel.

In particolare, ometti tali dichiarazioni:

  

rendendo fattibile la nostra attuale implementazione, ma meno che ottimale.

perché questo ti offrirà un "aggiustare il tuo codice" raccomandazione immediata da parte della maggior parte dei lettori.

Se le prestazioni di un'applicazione esistente (non scritta da te) sono influenzate, è diverso. Ad esempio, una volta che Linus prestò prontamente attenzione alla correzione delle prestazioni del kernel per il codice incasinato, perché quel codice faceva parte di make, anche se era orgoglioso del codice che aveva scritto e del fatto che non aveva bisogno di farlo quella soluzione esatta. Ad esempio, hai bisogno di un'applicazione che interessa a tutti o di una soluzione senza svantaggi. Quindi, cose come:

  

comportamento da un'altra applicazione (molto usata)

è valido, a condizione che l'utilizzo di tale applicazione non sia ritenuto irragionevole.

Infine, se ti riferisci al codice sorgente, probabilmente ti chiederanno di vedere la sezione interessata - pensa a concedere in licenza problemi con il tuo codice, se esistono, e risolvi prima uno di essi se vuoi rispondere rapidamente.

A proposito, questo è un resoconto parziale della mia esperienza lì: https://www.ohloh.net/accounts/Blaisorblade

Se vuoi, puoi contattarmi per aiutarti direttamente con una proposta di posta e consultarmi sulla discussione. Sono abbastanza occupato, ma potrei trovare un po 'più di tempo :-).

Answer 2

Bene, potresti provare a leggere Documentation / SubmittingPatches nell'albero dei sorgenti del kernel di Linux.

Answer 3

In un grande progetto, il modo migliore per ottenere una patch nell'albero principale è contattare la persona che mantiene il particolare pezzo di codice. Quindi, guarda il file MAINTAINERS Linux per vedere chi è formalmente il responsabile del codice che " sono cambiati e anche al Linux repository SCM del kernel per localizzare gli sviluppatori che hanno recentemente lavorato su quel codice. Per aumentare le possibilità che la patch venga accettata:

• assicurati che la tua patch sia di facile comprensione e segua gli standard di codice e documentazione esistenti,
• spiega chiaramente cosa raggiunge la tua patch,
• invia le tue modifiche in un formato appropriato (l'output di diff -up per Linux),
• assicurati che la patch possa essere applicata (e funzioni) in modo pulito sull'ultima versione del software (kernel Linux),
• include casi di test che dimostrano sia il problema che stai risolvendo sia il modo in cui la tua patch lo risolve, e
• non includere nel codice modifiche irrilevanti (ad es. formattazione).

È più probabile che una piccola correzione per un bug noto venga incorporata in un progetto rispetto alle grandi modifiche al codice che introducono una nuova funzionalità di utilità marginale o dubbia. In alcuni casi vale la pena in primo luogo presentare una segnalazione di bug attraverso il database di tracciamento dei problemi del progetto, quindi inviare una patch che risolva il problema specifico. Per evitare delusioni, se stai pensando di apportare una grande modifica, è meglio discutere la modifica e l'implementazione proposta con il manutentore prima di scrivere il codice.

Answer 4

Leggi la Documentation / SubmittingPatches, trova il MAINTAINER appropriato e, soprattutto, scopri dove sta avvenendo tutta la discussione davvero . Potrebbe non essere sulla stessa mailing list del kernel, ma forse su alcuni sottosistemi ML.

Quindi iscriviti a questo ML e invia la tua patch come RFC.

Non so se la tua patch sia invasiva, ma prova a dividerla in una coda di cambiamenti logici, ognuno con la sua spiegazione.

Answer 5

Non ho provato a inviare personalmente alcuna patch del kernel, e i mancano documenti in questo la zona.

Ma questa pagina sembra che possa indicarti la giusta direzione.

Answer 6

Su EDIT, la risposta potrebbe essere interessante come esempio. Immagino che il tuo requisito sia del tutto ragionevole, ma hai ragione che anche un test sul cambio di contesto potrebbe essere troppo costoso. Ma dal momento che il kernel ha un'implementazione del timer, non vedo perché non possa essere usato per evitarlo. Quindi, in effetti, suggerire una richiesta di miglioramento è la scommessa più sicura. Sono sorpreso dal fatto che suggerire di inviare una segnalazione di bug invece di una patch fosse così adatto. Puoi anche modificare tu stesso la patch per usare tu stesso i timer se desideri inviarlo, ma resta pronto per la discussione :-) Puoi anche aggiungere " abbiamo una correzione locale ma aggiunge alcuni test sul percorso rapido di cambio di contesto, ecco perché la patch è collegata come riferimento ma non dovrebbe essere applicata " ;. Disattivando il tuo codice, se è noto per essere cattivo, eviterai le dure revisioni della patch.

L'alternativa è eseguire alcuni benchmark e dimostrare che non vi è alcun impatto, ma se i timer sono praticabili quel codice verrà comunque rifiutato, o per provare da soli la soluzione del timer (potrebbe esistere qualcosa di meglio). Trova i benchmark che usano per lo scheduler del kernel; guarda il "recente" discussioni sulla patch di CFS Ingo (o Kolivas?) e prendere i loro parametri di riferimento.

Per quanto riguarda il supporto, gli sviluppatori del kernel non si preoccuperanno di " Websphere App Server " da solo, se fa cose irragionevoli, nemmeno quelle finanziate da IBM. Ma con la mia conoscenza limitata delle situazioni, chiudere periodicamente una JVM non ha senso, sembra solo un modo per documentare una perdita di memoria / instabilità, quindi l'attuale comportamento deve essere supportato.