4. Betriebssystem

Betriebssystem

  • ?

    Eine kurze technische(?) Frage (von einem der kein Interesse an der Teilnahme hat, wg. Zeit): Warum keine POSIX-API?

    Edit: Im übrigen kann ich mich nur Korbinian anschliessen 👍

    0
  • O

    @BorisDieKlinge
    Ich möchte nichts nur deshalb machen, damit ich in Zukunft etwas davon habe. Ich möchte gleich etwas davon haben. Wenn ich das OS dann am Router starten kann und es funktioniert, wäre das natürlich perfekt. Außerdem würde es schon reichen, wenn ich (bzw. das Team natürlich) damit bewiesen hat, dass es möglich ist, ein solches Projekt auf die Beine zu stellen und noch dazu es möglichst perfekt zu machen.

    In meiner Wohngegend werden entweder SAP- oder Embedded-Programmierer gesucht. Die Tatsache, dass ich mich mit Low Level schon beschäftigt habe, macht es leichter, die Low Level Programmierung anderer System zu lernen und ich kann auf den SAP-&%$)!§&/" verzichten...

    @Tim
    Es soll neu werden. Es gibt schon genug Betriebssysteme, die auf irgendeine Art POSIX unterstützen. Keiner braucht ein weiteres. POSIX korrekt zu implementieren, ist sowieso extrem schwer. Darüber, ob jetzt jemand ein nicht-POSIX-System braucht, lässt sich natürlich streiten. Die internen Datenstrukturen und Algorithmen für Betriebssysteme sind schon seit Jahre, wenn nicht gar seit dem Anfang, maximal in Details verändert bzw. verbessert worden. Ein neues Betriebssystem kann maximal mit gutem Support der Features für seinen Einsatzzweck (z.B. für einen Router die Netzwerkprotokolle), verbesserter Usability (hier vor allem beim Paketmanagment und der Administration einzelner wie auch mehrer Rechner) und einer vereinfachten API punkten. Programme wie cp, ls, grep, sed und co sollten (wenn sie überhaupt im OS auftauchen) mit wenigen Zeilen API realisierbar sein.

    0
  • A

    POSIX: halte ich auch nicht für wichtig, das man POSIX implementiert. Wenn ich ein POSIX-OS haben will, nimm ich BSD und selbst für Windows gibts von MS die "UNIX Services" (oder wie sich das nennt).

    Was ich genial finden würde, wäre endlich mal ein OS das eine C++-API hat. Also wo ich endlich mal nicht mit C rumhantieren muß. Und da stösst mir das hier schon mal schlecht auf:

    Eine kleine Roadmap wäre vielleicht diese:
    - libstandard mit verschiedenen Klasse z.B. string, list, array, map, ...

    Sorry, aber da kann man doch ne ISO-C++-Stdlib implementieren, oder? Das wäre das Minimum was ich von einem OS verlangen würde, das sich die API an der ISO-C++-Stdlib hält.

    Und dann schön in modernem C++ gegen das OS programmieren.

    Womit übrigens POSIX sowieso hinfällig wird. 😉

    0
  • P

    os_programmierer schrieb:

    In meiner Wohngegend werden entweder SAP- oder Embedded-Programmierer gesucht. Die Tatsache, dass ich mich mit Low Level schon beschäftigt habe, macht es leichter, die Low Level Programmierung anderer System zu lernen und ich kann auf den SAP-&%$)!§&/" verzichten...

    vielleicht möchtest du dir anschauen, wie fertige betriebssystemkernel arbeiten. hier --> http://www.nilsenelektronikk.no/
    findest du zwei, einer mit task switching, einer ohne.
    ansonsten gibt es (für PC's, aber nicht nur), noch dieses: --> http://www.freertos.org/
    (sehr rudimentär, aber nettes studienobjekt, zum auspropieren auf 'ne x86 kiste brauchst du den watcom compiler)
    🙂

    0
  • M

    Artchi schrieb:

    Sorry, aber da kann man doch ne ISO-C++-Stdlib implementieren, oder? Das wäre das Minimum was ich von einem OS verlangen würde, das sich die API an der ISO-C++-Stdlib hält.

    Geil Exceptions im Kernel. Ronny hat, als ich ihn bei seinem Betriebssystem-Projekt dazu gedraengt habe, Exceptions zu unterstuetzen, gemeint, dass die dafuer noetigen 15 K Zeilen (woher der die Zahl hat? whatever) ihm zu viel seien.

    0
  • P

    Mr. N schrieb:

    Geil Exceptions im Kernel.

    exception handling im kernel ist keine frage der programmiersprache. idealerweise muss die CPU das unterstützen und dann kann's vom betriebssystem abgefangen werden.
    🙂

    0
  • O

    @Artchi
    Ich habe daran gedacht, die STL zu verwenden, bin aber davon sehr schnell abgekommen. Zum ersten is die nicht wirlich stabil. Wenn man an c++ 0x denkt (hoffentlich bleibt das bei 0x), dann wird sie die Standard Bibliothek von c++ bald ändern. So viele 0x gibt es nicht mehr. Ich möchte nicht von anderen abhängig werden wieder bei der API. Zweitens is die die c++ stdlib einfach nur grauslig in vielen sachen. Beispielweise untersützt open von fstream keine std::string klasse als parameter. Das sind meine Gründe von den Standard-APIs abzugehen.
    Weiters muss API als solche noch definiert werden. Mit dem Kernel kann man sowieso nur per interrupt, sysenter/exit, callgate, ... kommunizieren. Die Programmiersprache is da unwichtig. Die restliche API wird immer mit services kommunizieren. Dabei werden einfache Nachrichten ausgetauscht. Auch hier ist die Sprache nicht wichtig. Es wird also nie DIE C++ API für das OS geben. Es ist immer nur ein Wrapper für die verscheidenen Methoden der Kommunikation mit anderen Prozessen oder dem Kernel.

    @pale dog
    danke. Ich werde sie mir ansehen.
    @pale dog 2.
    Die CPU hat damit nichts zu tun. Er meint c++ Exceptions, nicht CPU Exceptions.

    @Mr. N
    Exceptions sind sicher für den Anfang noch nicht wichtig, aber wohl dann bald danach. Man kann den Code dafür entweder selbst schreiben oder den vom GCC verwenden (compiliert wird sowieso alles mit dem g++). Der Code müsste sicher noch in manchen Teilen angepasst werden, damit er mit der OS-API zusammenarbeitet. Vielleicht hat er die Menge an Zeilen vom GCC, dort sind es aber ca "nur" 5500.

    0
  • R

    @pale dog:
    programmiersprachen-exceptions sind rein softwareseitig, und benötigen keinen extra hardware support

    in einem microkernel könnte man evtl die gcc libs nutzen um exceptions zu ermöglichen

    *edit*

    man muss anmerken, das programmiersprachen-exceptions in treibern grundsätzlich massive probeme erzeugen können

    und die gcc libs benötigen tls support, sonst können sie nicht thread-save arbeiten (was in einem mono/exokernel recht problematisch wäre)

    0
  • O

    @r0nny
    Ich kann dir nur zustimmen. Genauso stelle ich mir das auch vor. Die Treiber werden fast ausschließlich im Userspace als Plugins für die einzelnen Services laufen. Ich habe ein Dokument über TLS gefunden, mich aber noch nicht näher damit beschäftigt. Mit halbwegs guter Dokumentation sollte das aber schon implementierbar sein.
    Wäre schön, wenn du vielleicht am OS mitmachst. Was hast du bisher gemacht?

    0
  • P

    r0nny schrieb:

    @pale dog:
    programmiersprachen-exceptions sind rein softwareseitig, und benötigen keinen extra hardware support

    ach so, naja, mit sowas würde ich einen kernel nicht belasten. das macht ihn nur unnötig fett und (wahrscheinlich) langsam. hardware exceptions sind schon sinnvoll für die stabilität eines kernels. misalignment, division durch 0, zugriffe auf geschützte bereiche etc. sollten nicht zum absturz führen...
    🙂

    0
  • O

    Ich beschreib vielleicht einmal den Bootvorgang, wie ich ihn mir vorstelle:

    grob:
    Bootsector -> Second Stage -> Kernel

    detailierter:
    Bootsector:
    - Sammeln wichtiger Informationen über den PC. z.B. ACPI Memory Map
    - Laden des Second Stage per int 13h Extensions. Disketten hat eh kaum einer mehr heute.
    - Protected Mode

    Second Stage:
    - Virtual x86 Mode bereitstellen
    - Start aller Real Mode APIs (13h, 16h, ...) bzw Start der VBE
    - EXT3 Treiber starten
    - möglicherweise Konfigurationsdatei laden
    - Kernel-EXE laden
    - Alle dynamischen Bibliotheken für den Kernel laden (braucht ELF support im second stage)

    Kernel:
    - API zum Second Stage starten (falls sowas nötig ist...)
    - Segmentierung und Paging (neu) initialisieren
    - Prozess- und Speichermanagment starten
    - Informationen über geladenen Bibliotheken vom Second Stage übernehmen und in die Initialisierung einfließen lassen
    - Hardware Service laden (initialisiert vor allem CPU, ACPI, PCI, USB, ...)
    - Festplatten- und Dateisystem Service laden
    - weitere Services laden (z.B. input, graphics, console, network, log, ...)

    Das Hardware Service sollte im Allgemeinen für die Hardware zuständig sein, solange diese nicht von anderen Services verwaltet werden kann. Z.B. kann das Netzwerk Service alle Netzwerkkarten selbst verwalten bzw. das Speicher Service die Festplatten plus Controller.

    Vielleicht schreibt jemand seine Meinung darüber hier rein...

    0
  • R

    booten würd ich grundsätzlich erstmal per grub machen,

    auf anderen architekturen dann entweder grub2 oder per openfirmware

    auf einigen arm's gibts komische bootumgebungen, die wären dann haariger

    da es ein microkernel ist, halte ich es generell für sinnvoll früher oder später ein posix api service bereitzustellen

    auf real mode zeugs würde ich wenn möglich vollständig verzichten

    *edit* fixed typo

    0
  • P

    r0nny schrieb:

    auf einigen arm's gibts komische ootumgebungen, die wären dann haariger

    was sind ootumgebungen?

    0
  • O

    Hat grub einen Dynamischen Linker an Bord? Wenn nicht, dann is er leider maximal zum Laden des Second Stage geeignet.

    Außerdem möchte ich mich, da ich immer noch alleine bin, auf x86 und vielleicht dann später auf x86_64 beschränken.

    Wieso grad bei einem Microkernel eine POSIX-API? Nur, damit grub geht?

    Real Mode braucht man nur, wenn grub das nicht übernehmen kann.

    Es existiert schon ein Bootsector, der eine statische ELF-exe läd - derzeit noch von Floppy, später dann aber von Disk. D.h., dass man wenig umschreiben muss.

    0
  • R

    grub hat keinen dynamsichen linker an board, packt einen aber direkt in den 32 bit mode, und kann bereits service-module pre-loaden

    die grundlegenden dienste, die dynamisches laden usw bereitstellen sollten sowiso statisch in sich gelinkt sein, und des rest sollte einfach per fork von einem basisprozess der nur den dynamischen linker enthält (und alles weitere hinzulädt) erledigt werden

    *edit*

    posix api soll nicht im kernel sein, sondern als dienst angeboten werden, da einfach viele tools dann einfach portierbar sind, und bestimmte programmiersprachen posix als gundlage benötigen

    0
  • O

    In den Protected Mode komme ich schon selbst. Das ist nicht schwer. Dass grub Module laden kann, weiß ich. Aber ich weiß zum Zeitpunkt, an dem grub läuft, ja nicht, welche Bibliotheken der Kernel dann braucht.

    Wieso man POSIX als Dienst anbieten soll, ist mit nicht ganz klar. Es ist nur eine API. Eine Bibliothek sollte dafür reichen. Aber wie gesagt, ich möchte kein POSIX ebenso wenig Programmiersprachen, die das voraussetzen, wobei mir nicht ganz klar ist, welche Sprache von POSIX abhängt.

    Ich möchte die Tools selbst schreiben. Für einen Router braucht man ja keinen Compiler. Programme, wie die der coreutils sind schnell geschrieben.

    Wie schon davor im Thread gesagt wurde: Wenn man POSIX will, kann man ja existierende Betriebssysteme verwenden. Mir ist klar, dass POSIX verlockend ist, weil man dann die GNU Programme drauf laufen lassen kann. Aber ich möchte das maximal beim gcc machen. Der Teil der POSIX API, den der gcc verwendet, ist eh noch der einfacher aber z.B. die POSIX-Threads möchte ich echt nicht nachbauen müssen.

    0
  • M

    os_programmierer schrieb:

    Wieso man POSIX als Dienst anbieten soll, ist mit nicht ganz klar. Es ist nur eine API. Eine Bibliothek sollte dafür reichen.

    Auch fuer so obskure Dinge wie Signal Handling?

    0
  • O

    Gute Frage...
    Man könnte Signale in Messages verpacken. Beim Start einer POSIX-Anwendung wird ein separater Thread erstellt, der dann auf solche Messages wartet und die Handler aufruft. Dazu muss man nur die IPC API des OS in die der POSIX-Signale umwandeln. Der Aufruf von kill(2) erzeugt für das angegebene Signal eine Message, schaut nach, ob der Prozess mit der angegeben ID auch ein POSIX-Prozess ist (Das kann man leicht, indem man testet, ob der Zielprozess einen Signal-Handler-Thread hat.) und schickt ihm dann die Nachricht. Sollte der Zielprozess keinen Signal-Handler-Thread haben, ist es kein POSIX-Prozess und kill gibt dann ESRCH zurück. Ich denke, das wäre eine gute Lösung. Möglich wäre auch eine Lösung ohne separatem Thread. Es wird einfach eine Message Queue z.B. mit Namen "/posix/signals" erzeugt und sobald eine Message dort eintrifft, wird ein Handler aufgerufen, der dann den mit signal(2) bestimmten handler aufruft.

    Die ganze POSIX-API könnte man leicht in einer libposix unterbringen btw. Aber wie gesagt, mir wäre die native API lieber. Wenn ich sich aber jemand meldet, der die libposix schreiben will, bin ich klarerweise gerne bereit, denjenigen auch zu unterstützen.

    0
  • R

    das ist technisch nicht möglich, da posix signale eine art programminterupt sind

    der laufende main-thread wird unterbrochen und es wird einiges mit seinem stack angefangen

    *edit*

    man mönte des aber recht toll auf eine art "urgent messaging" system abbilden, das sicherstellt, das bestimmte nachrichten wie speicherzugriffsfehler, oder termination so schnell wie möglich behandelt werden

    *edit 2*

    wenn man das system ähnlich den posix signalen gestaltet, kann man das ganze sogar recht einfach 1:1 abbilden

    0
  • O

    r0nny schrieb:

    das ist technisch nicht möglich, da posix signale eine art programminterupt sind

    hmm Naja... Das Eintreffen einer Message kann genau das gleiche tun.

    r0nny schrieb:

    der laufende main-thread wird unterbrochen und es wird einiges mit seinem stack angefangen

    Was wird denn mit dem Stack angefangen?

    Die Message muss ja nicht urgend sein. In meinem Beitrag davor hab ich gemeint, dass man eine Message Queue einrichtet, die nur auf solche POSIX-Signal-Messages hört. Dazu wird ein Handler für das Eintreffen eines Signals installiert, der dann - das ist nicht so genau in meinem Beitrag herausgekommen - den Main-Thread unterbricht. Dieser Handler erkennt die Art des Signals und tut dann entsprechendes (Programm abwürgen, signal(2)-Handler starten, ...). Signale wie SEGFAULT oder SIGILL oder andere kommen vom Kernel. Dazu muss es im OS sowieso eine eigene API geben. Wenn man diese "Signale" vom OS dann per nativer API abfängt, kann man immer noch die POSIX-Handler aufrufen.

    r0nny schrieb:

    wenn man das system ähnlich den posix signalen gestaltet, kann man das ganze sogar recht einfach 1:1 abbilden

    Signale sind nichts anderes als Messages. Nur meistens ohne Inhalt. Allein das Eintreffen einer solchen "Message" ist schon Signal genug. 🙂

    0
Anmelden zum Antworten