Frage zum Aufbau eines OS



  • Hey Leute,
    ich habe mal einen allgemeine Verständnisfrage zum Aufbau eines OS, gerade im Bezuf auf eine API, Treiber und eine Bereitstellung einer Lib( z.B.: C-Lib ).
    Vielleicht kann mir einer mal kurz erklären wie das ganze aufgebaut ist, habe bisher leider nichts richtiges im Netz gefunden.
    Was genau ist denn nun ein Treiber? Ist das einfach nur eine Funktion vom Kernel die die Hardware steuert oder sind das ettliche solche Funktionen oder wie genau ist ein Treiber aufgebaut? Wie in dem Tutorial die Funktion k_printf, was genau ist diese Funktion? Ist solche eine Funktion und auch zum Beispiel die Funktion update_cursor Teil einer API des eigenen OS sowie bei Windows die WIN API? Und wie läuft es zwecks einer C-Lib ab? Wenn es für das OS User-Programme geben soll, muss man ja auch eine eigene C-Lib schreiben oder nicht? Es funktioniert ja nicht, wenn der User die C-Lib von Windows zum Beispiel statisch linkt!? Ich habe bei PrettyOS zum Beipsiel die ganzen Header und Sourcedateien wie stdio.h und stdio.c gesehen, sowie ettliche weitere von der C-Lib. Habt ihr die alle selber geschrieben?
    Das sind einige Frage, es wäre echt cool wenn ihr mir mal so einen kurzen Überblick über das alles und den ganzen Aufbau geben könntet=)

    Vielen Dank schonmal

    Lg freeG


  • Mod

    kernel: syscall.c <---> userlib.c <----> user-prg

    Treiber: http://de.wikipedia.org/wiki/Gerätetreiber

    WIN API? http://www.henkessoft.de/C++/WinAPI/WinAPI Kapitel 1 bis 6/api1.htm

    @fr33g: Du solltest dich auf den üblichen OSDev-Seiten einlesen. Das geht schneller, als hier solche einfachsten Grundfragen zu stellen, die man ruckzuck per Suchmaschine beantworten kann.



  • Ich habe mich eigentlich schon sehr gut und vor allem habe ich sehr viel eingelesen. Allerdings habe ich noch ein paar grundlegende Fragen, die ich bisher leider nicht beantworten konnte. Was ein Treiber ist, ist mir schon klar, aber ich verstehe den Aufbau noch nicht so ganz. In deinem Tutorial, hat man ja für die Textausgabe am Anfang nur k_printf, so ist das dann zu Beginn quasi auch der Treiber oder wie verstehe ich das? Genauso bei der Tastatur, da hat man auch nur die 3 Funktionen um die Tastenanschläge dann in die entsprechenden Codes umzuwandeln und dann zu erkennen was wan gedrückt wurde. Sind diese 3 Funktionen dann der Treiber oder wie muss ich das verstehen? Die Syscalls, sprich bei euch die userlib.c ist dann quasi das was bei Windows die WIN-API ist? Noch eine Frage zur C-Lib, ich erstelle ja die Header-Files und implementiere die Funktionen dann in den Sourcefiles, Userprogramme compilieren und linken dann diese Files mit zum Programm. Aber wie implementiert man denn die Userlib, zum Beispiel printf? Macht man das mit Hilfe der API, also Userlib.c, oder mit Hilfe der Treiber, also k_printf?

    Ich hoffe ihr könnt mir die Fragen vielleicht beantworten, da ich bisher leider echt nichts im Netz gefunden habe, Links tun es natürlich auch;-)

    Schonmal vielen lieben Dank

    Lg freeG



  • dein userprogramm hallo.c ruft printf auf, welches du in deiner libc implementiert hast. dieses printf ruft dann den syscall für kprintf auf, welches dann das ganze ausgibt.

    das sind zwar beides zusammen gesehen wohl eher treiber für eine terminalemulation aber so ungefähr geht das ganze vonstatten. nehmen wir beispielsweise eine netzwerkkarte: du rufst eine socket()-funktion auf, welche einen syscall aufruft welche dann die socket-spezifische funktion für die netzwerkkarte aufruft. hier brauchst du dann eine vernünftige treiberschicht, in welcher die richtigen treiber für die funktionen registriert werden z.b..



  • Ok vielen Dank, man kann das also noch nicht wirklich Treiber nennen:-P

    Wenn ich das richtig verstanden habe, sieht es doch so aus:
    Userprogramm.c => ruft printf aus stdio.c( selbst implementiert ) auf => dieses wiederum ruft mit einem Syscall das k_printf auf.
    So und dann hat man ja noch ne API, so wie bei Windows und diese Funktionen rufen auch mit Hilfe von Syscalls die entsprechenden Kernelfunktionen wie k_printf auf oder? Dann würde das ganze doch so aussehen:

    userprogramm.c => printf( stdio.c ) => a_printf( OSAPI.c ) => Syscall zu k_printf?

    Schonmal danke für die bisherigen Erläuterungen!

    Lg freeG



  • fr33g schrieb:

    Ok vielen Dank, man kann das also noch nicht wirklich Treiber nennen:-P

    Doch, schon. Der Treiber ist zwar wahrscheinlich nicht gut gekapselt und benutzt keine Treiberabstraktion, aber er spricht die Hardware an, also ist es ein Treiber.

    So ähnlich wie unser Prof uns immer gesagt hat, dass einfach drausloshacken auch ein Softwareentwicklungsprozess ist, nur eben kein besonders guter. 😉

    userprogramm.c => printf( stdio.c ) => a_printf( OSAPI.c ) => Syscall zu k_printf?

    Das Prinzip stimmt so, wobei es natürlich selten einen kprintf-Syscall gibt. Das Formatieren soll der Userspace bitteschön selber machen, und dann wird es entweder einen String auf den Bildschirm schreiben oder gleich nur ein allgemeines write auf eine Datei und die Datei ist zufällig ein tty.



  • Ok vielen Dank erst mal. Hast du einen Link oder so zwecks Treiberabstraktion? Also wie das im Normalfall so aussieht?

    Ok also das Prinzip stimmt schon, dass man die C-Lib so implementiert, dass diese eine Funktion der API aufruft und diese dann mittels Syscall eben eine entsprechende Kernelfunktion aufruft. Diese wiederum arbeitet dann mit dem Treiber zusammen oder?
    Wenn ich für mein OS nun ne andere Sprache zusätzlich anbieten möchte, müsste ich ja ne entsprechende Lib wieder implementieren und natürlich die OS-API in der entsprechenden Sprache.

    Ist die C-Standardbibliothek denn auch so implementiert, dass sie WIN-API Funktionen aufruft?

    Lg freeG



  • Also was die Treiberschnittstelle angeht, komme ich natürlich nicht umhin, dir CDI andrehen zu wollen. 😉
    http://lpt.tyndur.org/cdi/
    http://git.tyndur.org/?p=cdi.git;a=tree;f=include;h=b306a719a6385e2ec92ef1246fdb3203706b61db;hb=HEAD

    Den Begriff API würde ich vergessen. Du bezeichnest damit irgendeine Zwischenschicht, die es nicht wirklich gibt. Das, was du so bezeichnest, gehört alles zur libc. Andere Leute würden unter API die kernelseitige Syscall-Schnittstelle verstehen, das ist also missverständlich. Für eine andere Programmiersprache wirst du natürlich auch eine Runtime implementieren müssen (wobei nichts diese Runtime davon abhält, intern wieder libc-Funktionen zu benutzen).

    Ob ein Syscall direkt auf eine Treiberfunktion zugreift, hängt natürlich auch von der Architektur deines OS ab. In einem Mikrokernel hast du im Kernel keine Treiber und Syscalls machen neben Speicher- und Prozessverwaltung vor allem IPC, also Kommunikation mit anderen Prozessen (zum Beispiel Hardwaretreiber). In einem Monolithen sitzt das alles im Kernel und kommt deiner Vorstellung wahrscheinlich recht nahe.



  • Ich finde, das ganze klingt irgendwie ziemlich abstrakt, wenn man nicht wenigstens

    - ein wenig Assemblergrundlagen kennt,
    - die Notwendigkeit der Programmiersprache C gegenüber Assembler einigermaßen versteht
    - oder zumindest in groben Zügen über Realmode oder Protected Mode Grundlagen informiert ist
    - bzw. weiß, was ein Dos-Extender macht,
    - oder ahnt warum sich Leute die Mühe machen, ein Betriebsystem wie Qubes zu entwickeln.


  • Mod

    Qubes:

    In the future it might also run Windows apps.



  • [...] - die Notwendigkeit der Programmiersprache C gegenüber Assembler einigermaßen versteht

    Was ist z. B. mit MenuetOS?

    Ich selbst versuche mich an einem ähnlichen Projekt (reiner ASM - Code) und komme auch mit Assembler ganz gut zurecht (momentan habe ich ein paar Probleme, aber mit C hats auch nicht funktioniert 😞 ). Möglicherweise braucht man ein wenig länger, um sich einzuarbeiten, aber da das mein erstes OS ist, habe ich auch keinen Vergleich.

    Und ich sehe meine Entscheidung immer wieder bestätigt, wenn ich mir die Images vom ASM - OS und die von einem sehr einfachen C - OS (nur Textausgabe) anschaue:
    Assembler - Image: 1,15 KB
    C - Image: 47,9 KB

    ...und das trotz höchster Optimierungsstufe bei gcc! Was die Performance angeht, konnte ich noch keinen repräsentativen Vergleich durchführen, aber auch da bin ich optimistisch, dass man mit Assembler vorne liegt.


  • Mod

    Ja, asm ist eine Alternative. Schau Dir mal tatOS an.


Anmelden zum Antworten