4. Betriebssystem

Betriebssystem

  • O

    Betriebssystem

    Vor einiger Zeit habe ich begonnen, an einem Betriebssystem zu schreiben. Leider
    hatte ich immer weniger Zeit dafür, sodass es nicht wirklich weiter ging. Außerdem
    fehlte ein Team, das mitmacht und in dem man über verschiedene Dinge diskutieren kann.

    Mit diesem Beitrag versuche ich, so ein Team zu finden. Da das Betriebssystem in C++
    geschrieben werden soll, ist es wichtig, dass jeder wirklich sehr gut C++ kann.
    Assembler ist nur für spezielle Teile oder zur Optimierung nötig, sodass man das
    nicht unbedingt können muss. Wichtig ist, dass ich keine Neulinge suche. So leid
    mir das tut, aber ich hab das schon mehrmals probiert und keines Mal hat es geklappt.
    Bitte nicht böse sein.

    Es existiert bereits ein kleiner Teil von Code, der in den Protected Mode schaltet und
    dort zumindest die CPU erkennt. Außerdem schreibe ich gerade an einer standard Bibliothek
    ähnlich der STL von C++. Der erste Einsatzzweck soll es möglich machen, das OS als Router
    einzusetzen.

    Zusammenfassung:
    - Microkernel mit Services über IPC per Message Passing
    - keine Distributionen, zentrale Paketverwaltung
    - Pakete lokal kompilieren oder signierte binäre Pakete
    - ein Paket pro Zweck
    - viele Tests der Pakete
    - klares und standardisiertes Versionsmanagment
    - keine POSIX-API
    - ELF als binäres Format, ext3 als Dateisystem
    - Allgemein Implementierung von Standards.

    Details:
    - Das Betriebssystem besteht aus einem microkernel, der Speicher- und Prozessmanagment
    wie auch einen Teil des dynamischen Linkers übernimmt.
    - IPC geschieht per Message Passing. Einzelne Services übernehmen verschiedene Dienste,
    z.B. Netzwerk, Konsole, .... Der Kernel stellt eine API für IPC zur Verfügung, über die
    die einzelnen Programme mit den Services kommunizieren.
    - Ein wichtiger Teil soll das Paketmanagment sein. Ich möchte keine einzelnen Distribution
    haben sondern nur eine einzige. Pakete sollen lokal kompiliert werden können oder binär
    installiert werden. Binäre Pakete werden signiert, die Source wird in subversion Repositories
    gehalten, die per https abgefragt werden können.
    - Die Versionen sind ebenso wichtig. Versionen werden ausschließlich in der Form "major.minor.revision"
    verwendet. Änderungen an revision passieren nur für kleine Bugfixes. minor ändert sich, wenn
    zur existierenden API etwas hinzugefügt wird, ohne, dass Programme, die die ältere API verwenden
    nicht mehr funktionieren, oder wenn ein großer Teil des Codes eines Paketes verändert wurde.
    major-Änderungen passieren nur dann, wenn die API so verändert wurde, dass existierende Programme
    nicht mehr kompatibel dazu sind.
    - Zusätzlich is noch wichtig, dass es für einen Zweck nur ein Paket gibt. Ich möchte keinen redundanten
    Code. Das schafft nur mehr Code, der dann wieder getestet werden muss. Das bringt mich gleich zum
    nächsten Punkt: Jedes Stück Code wird ausführlich getestet - sofern das auch möglich ist. Nicht alles
    kann getestet werden. Es darf NIE der Fall sein, dass Testsuites fehlerhaft verlaufen, wie das leider
    bei manchen anderen Projekten der Fall ist.
    Als erstes Dateisystem soll ext3 implementiert werden. Als Format für binäre dateien wird ELF verwendet.

    Sofern möglich, soll das Team dann an einem Feature arbeiten, bis es fertig ist. Erst dann wird das
    nächste in Angriff genommen. Dadurch hoffe ich, halbfunktionierenden Code zu vermeiden. Wichtig ist
    auch lückenlose Dokumentation (in Englisch zwecks Internationalität :-)) für den (imaginären)
    Endanwender wie auch für interessierte Entwickler. Die Kommunikation kann wahlweise per Forum oder
    besser per XMPP laufen (Soll ein Zeichen für die Implementierung von Standards sein.). Meine XMPP
    Adresse ist mastamind@amessage.at. Hätte auch GPG, falls das jemanden interessiert.

    ich vermute, dass der Thread gleich geschlossen wird, da es heißen wird, dass das Projekt zu groß is
    und ich ja eh keine Ahnung hab. Dagegen kann ich kaum was tun. Ich hoffe nur, dass das nicht passiert.
    Wer Interesse hat, der möge bitte hier Fragen stellen bzw die Meinung äußern.

    hmm hiermit hab ich alle gesagt. Wer kein Interesse hat, soll bitte hier nicht die Idee schlecht machen.
    Danke.

    0
  • ?

    Bliebe noch die Frage der Lizenz.
    Wenn ich dein Beitrag richtig lese, möchtest du ein Auseinanderlaufen und Coversionen verhindern.

    Nur, was ist, wenn Du irgendwann keine Lust, Zeit, Muße mehr hast, an dem Projekt weiterzuarbeiten?
    Was geschieht dann mit der Arbeit, die auch andere investiert haben?

    Oder wenn ihr euch später mal nicht einigen könnt, und eine Seite des Teams möchte einen eigenen Ast weiterentwickeln.

    0
  • O

    Du hast richtig gelesen (und auch richtig verstanden :-)). Es geht mir sehr darum, dass nicht dieses Distributions-Chaos auftaucht. Wenn man z.B. bei gentoo schaut, dann is es fast unmöglich, dass ein einziges Paket ohne ein Patch installiert wird. Ich denke, dass das auch ein Problem der vielen Distributionen ist, die immer ihre eigenen Patches erstellen anstatt, dass einfach eine neue Version des Paketes für alle Distributionen erstellt wird. Das halte ich für weitaus sinnvoller.

    Was vielleicht nicht so klar rübergekommen ist, ist, dass ich nicht damit meine, dass alles an mir hängen muss. Ich meine damit, dass es nur eine Distribution gibt, die aber keineswegs an einer person hängt. Sicher ist es schwer so eine lizenz zu erfinden. Und die rechtliche Frage nach der Möglichkeit so eienr Lizenz is auch für mich nicht beantwortbar, da ich kein Rechtsanwalt bin.
    Über die Lizenz muss aber sowieso noch diskutiert werden. Auch wenn wahrscheinlich viele denken, dass es eh nichts wird und so weiter, muss man das trotzdem am Anfang klären. Mir schwebt vor, dass es etwas in Richtung LGPL geht, wobei mir aber wichtig wäre, die Verwendung für bestimmtes staatliche Organisationen auszuschließen, z.B. Polizei, Geheimdienste, Militär, ... Klingt hier sicher komisch, wenn noch nichts Verwendbares vorhanden ist, wäre mir aber wichtig, is aber nur ein Vorschlag. Wichtig is auch, dass am Prozessor selbst keine closed source läuft. Closed Firmwares in Treibern is mir egal.

    Das mit dem fork is sicher zu bedenken. Die Frage is nur, wie sehr es einen fork geben kann oder soll. Die meisten Punkte, die ich im ersten Beitrag geschrieben habe, sind für mich absolut bindend. Über die will ich nicht diskutieren, weil sie genau eben das Betriebssystem ausmachen. Sonst bin ich offen für alle Arten von Diskussionen. Mir fällt so deshalb kein Grund ein, weshalb ein kompletter fork nötig wäre.
    Ich stelle mir ein vergleichbares System wie bei gentoo vor, bei dem einzelne Features eines Paketes per USE-Flags an- und abgeschaltet werden können. Solange das dann im Paketmanager ein standardisiertes Feature is, wird das sicher keine Probleme sein.

    ich hoffe, ich habe alle fragen beantwortet.

    0
  • O

    Anscheinend gibt es kein Interesse daran... Vielleicht beschreibe ich noch ein paar Ideen. Es wäre z.B. auch sehr hilfreich, wenn sich jemand finden würde, der auch nur einen kleinen Teil programmiert. Beispielweise wären viele Algorithmen zu implementieren. Oder auch nur die Bibliothek für das Lesen von ELF Dateien.

    Eine kleine Roadmap wäre vielleicht diese:
    - libstandard mit verschiedenen Klasse z.B. string, list, array, map, ...
    - libelf für das Lesen (und spätere Schreiben) von ELF-Dateien.
    - libext3 (oder nur ext) als Treiber für das Dateisystem.
    - Bootsector (es existiert bereits ein Bootsector, der muss aber neugeschrieben werden teilweise. z.B. braucht es Support für die int 13h Extensions zum Lesen von usb-sticks und festplatten)
    - einen Second Stage, der vom Bootsector geladen wird. Er muss ext3 lesen können und verwendet (wenn möglich) den v86-Mode um auf das Bootmedium zuzugreifen (über die den int 13h Support im Bootsector).
    - den eigentlich Kernel vorerst als statisch gelinkte ELF-exe. Später dann soll ein Teil des dynamischen Linkers im second stage sein, damit der Kernel dynamisch gelinkt sein kann.) Der Kernel soll grad ein paar Zeilen ausgeben.

    das wär mal was für den Anfang. Ob man dann weiter versucht, den Bootvorgang zu verbessern oder lieber am Kernel weiterbaut, kann man ja dann später entscheiden.
    Vielleicht interessieren sich jetzt mehr Leute dafür.

    0
  • M

    os_programmierer schrieb:

    Vielleicht interessieren sich jetzt mehr Leute dafür.

    Zu viele Leute haben ein Betriebssystem angefangen und nicht beendet.

    0
  • B

    Ich würd gern mitmachen 🙂 Allzuviel Zeit hab ich allerdings nicht, nur eine halbe bis ganze Stunde pro Tag... Wenns sehr viel Spaß macht (womit ich eigentlich rechne), dann kann ich auch ein wenig mehr investieren. Ich hab ehrlich gesagt keine Ahnung, ob ich "gut genug" bin, schließlich ist das sehr subjektiv 😕

    Groß Erfahrungen im Team-Programmieren hab ich nicht, jedenfalls nicht mit richtiger Versionierung. Hab mich auch vor ein paar Wochen ein wenig in die OS-Programmierung eingearbeitet, ist aber an einem fehlenden Diskettenlaufwerk gescheitert (Bochs wollte nicht so wie ich wollte) 🤡

    Sag Bescheid wenn du mich im Team haben willst, dann rücke ich meine E-Mail raus oder schreib dir 🙂

    Edit: Assembler war ich auch mal fit drin, ist aber schon 4 Jahre her 😃

    0
  • O

    Ich weiß. Ich kenne genug. Ich will aber nicht zu denen gehören. Ich glaube, dass ein Team sicher dazu beitragen kann, dass das Projekt weiter geht. Wobei ein Betriebssystem wohl eh kaum je wirklich fertig ist. Aber ich glaube, dass man es in 6 Monaten mit einem guten Team zumindest als simplen Router einsetzen kann. Man muss nur diese 6 Monate überbrücken. Ich möchte jetz noch nicht aufgeben. Das kann ich in 6 Monaten immer noch 🙂

    Wie schon im Beitrag davor gesagt, wäre ich auch froh, wenn jemand einen kleinen Teil übernimmt. Außerdem möchte ich beweisen, dass es möglich ist, ein eigenes Betriebssystem zu schreiben. Es braucht nur ein motiviertes und kompetentes Team - in dem Fall kompetent in oop, c++ und für gewisse Aufgaben auch Low Level. Ich hab auch nicht erst vor 3 Wochen mit c++ angefangen.

    Ich weiß, ich bin nicht gut im Motivieren von Leuten. Aber ich hoffe halt, dass sich jemand wirklich angesprochen fühlt und sich auch immer gedacht hat, dass er es besser kann als <derzeit verwendetes Betriebssystem einsetzen>.
    Dass der Erfolg nicht vorprogrammiert ist, ist klar, aber der Misserfolg ist es, wenn sich niemand traut. Es gibt viele coole Dinge, die nur darauf warten, implementiert zu werden 🙂 Vielleicht kann ich auch gerade die Leute ansprechen, die mit einem Betriebssystem begonnen haben, es aber nie beendet haben. Sie hätten die Chance, dass ein Teil ihres Codes in diesem Versuch aufgeht.

    @Badestrand
    Das wird sich herausstellen. Aber grundsätzlich gilt, dass ich auf jeden Fall jeden gerne in das Team aufnehme. Wenn du pro Tag so viel Zeit hast, ist das eh sehr viel. Wenn du willst, kannst du aber gerne hier sagen, wie du dich einschätzt, da es vielleicht andere motiviert, auch mitzumachen oder zumindest darüber nachzudenken.
    Ich kann dir auch gerne bei deinem bochs-Problem helfen. Ich hab bis jetzt auch immer bochs eingesetzt, bin aber draufgekommen, dass qemu vielleicht besser wäre.

    0
  • B

    was hast du später von deinem Betriebssystem? Was erhoffst du dir später alles damit machen zu können?

    0
  • K

    Ich wuerde mal sagen, er hat dabei ne Menge gelernt. Allein das ist/war den Aufwand wert!

    0
  • ?

    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
Anmelden zum Antworten