4. Betriebssystem

Betriebssystem

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