Wie versteht man den GNU-Quellcode?

Es tut mir wirklich leid, wenn das irgendwie dumm klingt. Ich habe gerade K&R gelesen und an einigen Übungen gearbeitet. Diesen Sommer denke ich für mein Projekt darüber nach, ein Linux-Dienstprogramm neu zu implementieren, um mein Verständnis von C weiter zu erweitern, also habe ich die Quelle für GNU tar und sed heruntergeladen, da beide interessant erscheinen. Allerdings fällt es mir schwer zu verstehen, wo es anfängt, wo die Hauptimplementierung ist, wo all die seltsamen Makros herkommen usw.

Da ich viel Zeit habe, ist das eigentlich kein Problem. Soll ich mich zuerst mit der GNU-Toolchain (z. B. make, binutils usw.) vertraut machen, um die Programme zu verstehen? Oder sollte ich vielleicht mit etwas Kleinerem beginnen (falls es so etwas gibt)?

Ich habe wenig Erfahrung mit Java, C++ und Python, falls das wichtig ist.

Danke!

Die GNU-Programme sind groß und kompliziert. Die Größe von GNU Hallo Welt zeigt, dass selbst das einfachste GNU-Projekt viel Code und Konfiguration benötigt.

Die Autotools sind für Anfänger schwer zu verstehen, aber Sie müssen sie nicht verstehen, um den Code zu lesen. Selbst wenn Sie den Code ändern, können Sie in den meisten Fällen einfach make ausführen, um Ihre Änderungen zu kompilieren.

Um Code zu lesen, benötigen Sie einen guten Editor (VIM, Emacs) oder eine IDE (Eclipse) und einige Tools zum Navigieren durch die Quelle. Das TAR-Projekt enthält ein src-Verzeichnis, das ist ein guter Ausgangspunkt. Ein Programm beginnt immer mit der Hauptfunktion, also tun Sie es

grep main *.c

oder verwenden Sie Ihre IDE, um nach dieser Funktion zu suchen. Es ist in Tar.c. Überspringen Sie nun den ganzen Initialisierungskram, bis

/* Main command execution.  */

Dort sehen Sie einen Schalter für Unterbefehle. Wenn Sie -x übergeben, geschieht dies, wenn Sie -c übergeben, geschieht dies usw. Dies ist die Verzweigungsstruktur für diese Befehle. Wenn Sie wissen möchten, was diese Makros sind, führen Sie Folgendes aus:

grep EXTRACT_SUBCOMMAND *.h

dort können Sie sehen, dass sie in common.h aufgeführt sind.

Unter EXTRACT_SUBCOMMAND sehen Sie etwas Lustiges:

read_and (extract_archive);

Die Definition von read_and() (erneut mit grep erhalten):

read_and (void (*do_something) (void))

Der einzelne Parameter ist a Funktionszeiger wie ein Rückruf, also liest read_and angeblich etwas und ruft dann die Funktion auf extract_archive. Nochmals, grep darauf und Sie werden Folgendes sehen:

  if (prepare_to_extract (current_stat_info.file_name, typeflag, &fun))
    {
      if (fun && (*fun) (current_stat_info.file_name, typeflag)
      && backup_option)
    undo_last_backup ();
    }
  else
    skip_member ();

Beachten Sie, dass die eigentliche Arbeit beim Anrufen stattfindet fun. fun ist wiederum ein Funktionszeiger, der in Prepare_to_Extract gesetzt wird. fun kann darauf hinweisen extract_fileder das eigentliche Schreiben übernimmt.

Ich hoffe, ich habe Ihnen dabei viel geholfen und Ihnen gezeigt, wie ich durch den Quellcode navigiere. Wenn Sie diesbezügliche Fragen haben, können Sie mich gerne kontaktieren.

Das Problem mit Programmen wie tar Und sed ist zweifach (das ist natürlich nur meine Meinung!). Erstens sind sie beide wirklich alt. Das bedeutet, dass sie im Laufe der Jahre von mehreren Personen mit unterschiedlichen Codierungsstilen und unterschiedlichen Persönlichkeiten betreut wurden. Für GNU-Dienstprogramme ist es normalerweise ziemlich gut, da sie normalerweise einen einigermaßen konsistenten Codierungsstil erzwingen, aber es ist immer noch ein Problem. Das andere Problem ist, dass sie unglaublich sind tragbar. Normalerweise wird „Portabilität“ als eine gute Sache angesehen, aber wenn man es auf die Spitze treibt, bedeutet es, dass Ihre Codebasis am Ende voller kleiner Hacks und Tricks ist, um unklare Fehler und Eckfälle in bestimmten Hardware- und Systemteilen zu umgehen. Und für Programme, die so weit portiert sind wie tar Und seddas heißt, es gibt ein viel von Eckfällen und unklarer Hardware/Compiler/Betriebssysteme, die berücksichtigt werden müssen.

Wenn Sie C lernen möchten, ist es meiner Meinung nach der beste Ausgangspunkt, nicht zu versuchen, Code zu studieren, den andere geschrieben haben. Versuchen Sie es lieber schreiben selbst codieren. Wenn Sie wirklich mit einer bestehenden Codebasis beginnen möchten, wählen Sie eine, die aktiv gepflegt wird und in der Sie die Änderungen sehen können, die andere Leute vornehmen wie sie sie machenverfolgen Sie die Diskussionen auf den Mailinglisten und so weiter.

Mit etablierten Programmen wie tar Und seddu siehst das Ergebnis von den Diskussionen, die stattgefunden hätten, aber man kann nicht sehen, wie Software-Design-Entscheidungen und -Änderungen in Echtzeit getroffen werden. Das kann nur mit aktiv gewarteter Software passieren.

Das ist natürlich nur meine Meinung, und wenn Sie möchten, können Sie es mit Vorsicht genießen 🙂

Warum laden Sie nicht die Quelle der Coreutils herunter (http://ftp.gnu.org/gnu/coreutils/) und werfen Sie einen Blick auf Tools wie yes? Weniger als 100 Zeilen C-Code und ein voll funktionsfähiges, nützliches und wirklich einfaches Stück GNU-Software.

GNU Hallo ist wahrscheinlich das kleinste, einfachste GNU-Programm und leicht zu verstehen.

Ich weiß, dass es manchmal ein Chaos ist, durch C-Code zu navigieren, besonders wenn man nicht damit vertraut ist. Ich schlage vor, dass Sie a verwenden Werkzeug Das hilft Ihnen beim Durchsuchen der Funktionen, Symbole, Makros usw. Suchen Sie dann nach der Funktion main().

Natürlich müssen Sie sich mit den Tools vertraut machen, aber Sie müssen kein Experte werden.

Erfahren Sie, wie man es benutzt grep Wenn Sie es noch nicht kennen, verwenden Sie es, um danach zu suchen hauptsächlich Funktion und alles andere, was Sie interessiert. Möglicherweise möchten Sie auch Code-Browsing-Tools wie verwenden ctags oder cscope Das kann auch mit vim und emacs integriert werden oder eine IDE verwenden, wenn Ihnen das besser gefällt.

Ich empfehle die Verwendung ctags oder cscope zum Stöbern. Sie können sie mit verwenden vim/Emacs. Sie sind in der Open-Source-Welt weit verbreitet.

Sie sollten sich im Repository jeder größeren Linux-Distribution befinden.