Vorschlag für Euer Projekt



  • Hallo!

    Bin gerade beim Durchackern des Buchs "Understanding the Linux Kernel". Da Zusammenhänge verstehen aber besser mit Code funktioniert, der nicht hochoptimiert ist, hab ich mir auch Euren Code gesaugt und schaue immer wieder neugierig rein, wie gewisse Dinge realisiert sind. Der Linux Code ist da nicht ganz so leicht nachvollziehbar.

    Auch das Tut von henkessoft.de ist spitze!
    Euer OS wirbt ja speziell damit, dass es leicht sein soll, sich in das Thema einzuarbeiten. Leider sind viele Codeabschnitte aber nur sehr schlecht bis garnicht kommentiert. Gerade durch eine gute Doku (in Form von gut kommentierten Code) könntet ihr euch deutlich von anderen OS abheben, denn davon gibt es zum Thema OS nicht gerade viel.

    Bei uns in der Arbeit ist es Standard, am Beginn jeder Funktion ein Kommentar zu schreiben, was die Funktion macht. Nicht viel, es reicht ein Satz oder gar ein oder zwei Stichworte, die einem helfen, sich zurechtzufinden. Ich denke, das würde bei Eurem Projekt bereits reichen, um das ganze für Einsteiger einfacher zu gestalten.

    Ansonsten aber ein tolles Projekt bei dem man viel lernen kann! Danke dafür an alle Entwickler!

    P.S.: Aus Interesse: Welche Aufgaben stehen denn noch an? Wenn man mitarbeiten möchte, wo gebe es denn was zu tun?



  • Vielen Dank für das Lob und die konstruktive Kritik 🙂

    Euer OS wirbt ja speziell damit, dass es leicht sein soll, sich in das Thema einzuarbeiten. Leider sind viele Codeabschnitte aber nur sehr schlecht bis garnicht kommentiert. Gerade durch eine gute Doku (in Form von gut kommentierten Code) könntet ihr euch deutlich von anderen OS abheben, denn davon gibt es zum Thema OS nicht gerade viel.

    Bei uns in der Arbeit ist es Standard, am Beginn jeder Funktion ein Kommentar zu schreiben, was die Funktion macht. Nicht viel, es reicht ein Satz oder gar ein oder zwei Stichworte, die einem helfen, sich zurechtzufinden. Ich denke, das würde bei Eurem Projekt bereits reichen, um das ganze für Einsteiger einfacher zu gestalten.

    Ja, da hast Du Recht.
    Grundsätzlich versuchen wir, sprechende Funktions- Typen- und Variablennamen zu wählen, sodass manche Kommentare möglichst garnicht erst notwendig werden. Allerdings ist das nicht ganz flächendeckend der Fall, und natürlich ist es oft auch nötig, bestimmte Verhaltensweisen einer Funktion zu erklären, die garnicht in den Namen passen. Vieles ist da leider im Moment tatsächlich undokumentiert. Wir versuchen immer mal wieder, mit Code-Reviews die Dokumentation und Verständlichkeit einzelner Code-Abschnitte zu verbessern, aber das ist natürlich eine Menge Arbeit (und als Entwickler des Codes ist einem manchmal natürlich auch nicht so ganz klar, wo Erklärungen fehlen, weil man selbst ja weiß, wie es funktioniert), die auch leider etwas langweiliger als die Weiterentwicklung ist. Darum kommt sie leider manchmal auch zu kurz.

    Wenn Du Stellen findest, wo es besonders heftig ist, sag Bescheid, dann schauen wir uns das mal vorrangig an.

    P.S.: Aus Interesse: Welche Aufgaben stehen denn noch an? Wenn man mitarbeiten möchte, wo gebe es denn was zu tun?

    Im Moment ist die Umsetzung von Ordnerunterstützung sowie eine Neuimplementation der Ramdisk angedacht. Auch USB3 (xHCI) wäre ein interessantes Thema.
    Außerdem ist natürlich die Entwicklung von Treibern für weitere Netzwerkkarten, Soundkarten, Dateisystemen, ... jederzeit eine nützliche Sache.
    Und Userprogramme können jederzeit entwickelt werden, oder bestehende ergänzt werden. Das Programm calc.elf z.B. berechnet (-5)*-5 falsch, da ist ein Bugfix nötig. Der kürzlich implementierte Editor (Editor.elf) kann noch fast nichts, da ist auch noch viel Luft nach oben.


  • Mod

    Ein einfacher Textbrowser wäre auch schön, browser.elf zeigt RAW html Code



  • zum Beispiel ist mir Euer Memory Management nicht ganz klar.

    Hab folgende Tabelle gefunden. Handelt es sich dabei um virtuelle oder physikalische Adressen?
    Dazu passend auch memory.h, wo nicht ganz klar ist, ob es sich jetzt um physikalische oder virtuelle (lineare) Adressen handelt.

    Hier die Tabelle:

    0 MB - 16 MB         For DMA only. Kernel code resides somewhere inbetween, I think
    16 MB - 20 MB        For placement allocation while the heap is not set up. Here resides
                           - "Physical" bit table                        (128 KB)
                           - Kernel page directory                       (circa 8 KB)
                           - Kernel's page tables for 0 MB - 20 MB       (20 KB)
                           - Kernel's page tables for 3 GB - 4 GB        (1024 KB)
                           - Heap's "region" list (nongrowable)          (Remaining)
    20 MB - 3 GB         Intended for user programs' code, stack, heap
    3 GB - 0xFFF00000    For the kernel heap only; malloc'd memory resides here
    0xFFF00000 - 4 GB    Memory mapped stuff. E.g. for the PCI area.
    

    Grundsätzlich stell ich mir das ja ungefähr so vor:
    Virtuell:
    ---------
    Die unteren 3GB Userspace
    Die oberen 1GB Kernelspace

    Physikalisch:
    -------------
    Die untersten Bereiche für den Bootloader, Kernelcode, Placement Speicher, diverse von Intel genutzte, nicht verwendbare Speicherbereiche.

    Weiter oben dann der Bereich für die Userprogramme. Jeder Prozess hat die Paging Tabelle so aufgebaut, dass seine untersten 3GB ihm gehören, während der Rest für den Kernel ist. Da jeder Prozess seine eigenen Paging Tabellen hat, hat jeder Prozess 0-3GB zum adressieren.

    Ein Pageframe im RAM gehört wirklich nur einem Prozess? Oder bekommt da jeder Prozess so ein bisschen was davon ab? Wenn ja, wie schützt ihr die Speicherbereiche ggü. anderen Prozessen?



  • zum Beispiel ist mir Euer Memory Management nicht ganz klar.

    Guck mal nach /documentation/memory.txt

    Ein Pageframe im RAM gehört wirklich nur einem Prozess? Oder bekommt da jeder Prozess so ein bisschen was davon ab? Wenn ja, wie schützt ihr die Speicherbereiche ggü. anderen Prozessen?

    Der Prozess allokiert ja nicht selbstständig pyhsische Adressen. Das tut der Kernel. Die virtuellen Adressräume hat jeder Prozess für sich, die werden nicht geteilt, die Zuweisung pyhsischen Speichers macht der Kernel. Die physischen Adressen werden natürlich geteilt, aber die Prozesse wissen von den physischen Adressen ohnehin nichts.



  • Mr X schrieb:

    zum Beispiel ist mir Euer Memory Management nicht ganz klar.

    Guck mal nach /documentation/memory.txt

    Ein Pageframe im RAM gehört wirklich nur einem Prozess? Oder bekommt da jeder Prozess so ein bisschen was davon ab? Wenn ja, wie schützt ihr die Speicherbereiche ggü. anderen Prozessen?

    Der Prozess allokiert ja nicht selbstständig pyhsische Adressen. Das tut der Kernel. Die virtuellen Adressräume hat jeder Prozess für sich, die werden nicht geteilt, die Zuweisung pyhsischen Speichers macht der Kernel. Die physischen Adressen werden natürlich geteilt, aber die Prozesse wissen von den physischen Adressen ohnehin nichts.

    Die Zuweisung macht der Kernel, ok, aber angenommen einem Prozess A werden 64byte von einem 4kb Pageframe über malloc zugewiesen.
    Prozess B bekommt die darauffolgenden 32byte.
    Wie verhindert ihr, dass Prozess A nicht über seinen Bereich hinausschreibt und die Daten von Prozess B zerstört?
    Die CPU sieht ja nur dass der Pageframe sowohl von A als auch von B referenziert werden darf, also soweit alles ok. Naja, und der Kernel hat ja darauf auch keinen Einfluss, denn die Adressumsetzung mach ja die HW. Trotzdem könnte man ja so die Daten zerstören?



  • Ein Prozess kann nur ganze Pages allokieren.



  • Ein Prozess kann nur ganze Pages allokieren.

    OK.

    Die Tabelle in der Doku ist gut!

    Danke für die Beantwortung der Fragen.


Log in to reply