Bei dieser Frage geht es um die Wartung und das Testen der Konfiguration.
Bei falscher Verwendung verringern #ifdef, #ifndef, #elseif, #elif, #else, #endif Präprozessoranweisungen nicht nur die Lesbarkeit und Wartbarkeit von C-Code, sondern erhöhen auch das Risiko von Regressionsfehlern (z. B. wenn eine bestimmte Build-Konfiguration für einen bestimmten Zeitraum nicht getestet wurde Zeit).
Ich frage mich, wie der Linux-Kernel in der Lage ist, die enorme Menge an Konfigurationsoptionen beizubehalten, ohne in eine vollständige Wartungshölle zu geraten?
Ich verstehe, dass dies notwendig ist, um für alle Arten von Hardware flexibel zu sein, aber die schiere Anzahl der Konfigurationsoptionen sieht für mich als Anwendungsentwickler wirklich beängstigend aus.
Welche der folgenden Aussagen würden Sie als wahr betrachten?
#ifdef's nur für klar trennbare Codeabschnitte erlaubt, wo es sinnvoll ist, eine Funktion zu deaktivieren (und die richtigen Leute, die diese Entscheidungen treffen) EDIT: Ich habe festgestellt, dass es Testmaschinen gibt, die zufällige Konfigurationen auswählen und prüfen, ob sie gebaut und gebootet werden. Diese einfachen Build- / Boot-Tests können jedoch keine ernsthaften Regressionen erkennen, außer Bugs, die alles kaputt machen
Ich arbeite direkt mit dem Linux-Kernel und "Das u-boot". Bei weitem habe ich nicht genug Erfahrung, aber ich werde es versuchen.
Soweit ich das beurteilen kann, besteht die Konfigurationsdatei, über die Sie sprechen, tatsächlich aus mehreren Dateien, von den meisten allgemeinen Dingen wie CPU-Architektur und ähnlichem bis zu sehr detaillierten Dingen wie RAM-Frequenz und dergleichen.
Ja, es ist sehr und ich meine sehr beängstigend, aber wie Sie sagten, mit sehr guter (zumindest anständiger Dokumentation) muss das Projekt weitergehen. Außerdem müssen Sie die große Anzahl von Leuten erkennen, die an all dem Zeug arbeitet, das sich dort befindet. Sicherlich gibt es niemanden, der sich als echten Kenner von alles betrachten kann.
Nicht 100% sicher, aber ich denke, Sie haben Recht, da die meisten Anbieter zumindest einige Standardkonfigurationen verwenden. Stellen Sie sich zum Beispiel vor, dass die meisten Smartphones über die gleiche allgemeine HW-Architektur (CPU, GPU, RAM, usw.) verfügen, so dass Sie nicht unbedingt alles anpassen müssen.
Auch ja, der Hauptcode ist voll von
%Vor%und das hat offensichtlich Vor- und Nachteile. Aber das ist eines der schönen Dinge an C (und auch an C ++), es erlaubt alles zu kontrollieren . Quit Empowerment manchmal, manchmal ein echter Albtraum.
Nichts zum Testen hinzuzufügen:)
Linux-Projekte und ihre Kernal Maintenance verwenden das gleiche Framework, mit dem andere Open-Source-Software verschiedene Aspekte des Konfigurationsmanagements behandelt.
Es gibt drei Elemente, um einen Kernel auf diese Weise zu pflegen: Erstellen des Repositorys, Aktualisieren und Pflegen desselben und Integration in die Build-Infrastruktur.
Aber Linux Architektur Unterschiede und werden in der Regel in Modulen behandelt, und Protokoll Kommentare oft als eine Geschichte Spur gelesen, die beschreiben, wie eine Datei entwickelt hat.
Der Code jeder Version befindet sich in einem separaten Verzeichnis und fügt Beiträge und Patches zu einem "neuesten" Verzeichnis hinzu. Beiträge kann nur von den Moderatoren auf das Repository angewendet werden. Wenn eine neue Version erstellt wird, wird die neueste Version in eine neue Version dupliziert Release-Verzeichnis, um es zu konservieren, selbst wenn die Entwicklung fortfährt.
Dies ist der Grund, warum Sie normalerweise nur zwei Zweige in der Linux-Kernel-Entwicklung sehen - einen stabilen Release-Zweig und einen Entwicklungszweig.
Tags und Links linux maintenance linux-kernel c-preprocessor configure