eure vorstellung von einer guten os->userspace api ?



  • ich bin grade dabei ein Betriebsystem in Form eines exokernel-microkernel gemischs zu schreiben,

    und bin grade dabei es von "startet grad so" nach "ist interaktiv" weiterzuentwickeln

    deshalb will ich hier eine Diskussion anregen, was ihr als sinnvolles api-set für die Userspace<->Systemspace Interkation betrachtet, um schon auf diese zuzuarbeiten

    beachtet dabei bitte, das es nicht um das Minimalset, um Daten zu transferieren geht (mit denen man den Rest Wrappen könnte) , sondern um die gesammte API

    ich werd dann später meinen Senf dazu abgeben :p



  • mit posix hättest du den vorteil, gleich jede menge programme dafür zu haben. Weiß nicht ob das ein Kriterium ist, man kann sich auch Wrapper bauen. Ansonsten, alles-ist-eine-datei finde ich sehr praktisch.



  • Devices als Schnitstelle zu benutzen bietet sich an, für Daten austausch. Man könnte aber sicher eine schönere Schnitstelle als man: ioctl(2) finden 😉

    POSIX würde ich nicht direkt beachten, da einige Teile leider durch die lange und uneinheitliche Unix Entwicklung umständlich oder kompliziert geworden sind. Generell kannst du dir POSIX als Ratgeber benutzen, aber die eigentlichen POSIX Aufrufe würde ich dann lieber als Kernel-Identity implementieren (naja, ich kenne mich mit dem Exo Prinzip nicht wirklich aus).

    Außerdem brauchen wir nicht das XXte OS, dass POSIX implementier(t/en will), sondern mal ein paar frische Ideen (Nein, kein Windows :)).



  • kingruedi: ich will ja n paar ideen für die neue api, das posix als personality kommt ist sowiso schon "geplant" (will net, muss aber - wg. xorg)

    bisher habe ich folgende vorstellung davon:

    jede sache kann entweder sachen verwalten, oder io operationen durchführen
    deshalb hatte ich an eine datei/ordner dualität gedacht

    alles in allem soll die main personality auf massives threading, und gut gecachtes async io ausgelegt sein

    vom kernel bekommt man grundsätzlich nur events oder c++-exceptions



  • Verhinderst du somit nicht jede Sprache außer C++?



  • neben c++ sind auch andere sprachen exception fähig

    und es wird nen krassen hack geben, der auch exception-freie sprachen behandelt

    da die exceptions nocht direkt vo, kernel in den userspace fallen können (isr-beschränkung, sicherheitsaspekte) wird es eine art brücke geben, indem der kernel dafür sorgt, das der thread sich nach dem zurückspringen im status eines funktionsaufruf zum exception-getter befindet, der vom kernel mitgeliefert wird
    vorerst wird das ganze nur c/c++ können - später kommt dann support für den rest

    da es sowiso andere personalities geben wirs ist es ned so tragisch, wenn ned alle sprachen direkt unterstützt werden


Anmelden zum Antworten