Thema: Allgemeine Fragen

[Programm Noob]

Wie ihr es vielleicht schon in Wiki gelesen habt, hab ich die Schauze voll von diesen nicht funktionierdem kaputten zusammenkopiertem Code-Berg.
Deshalb rewrite ich NandOS und will einiges besser und ein paar Sachen voher besser planen. Deshalb habe ich ein paar Fragen dazu.

Frage 1: Auf was muss ich achten, das ich später ohne Probleme 64 Bit unterstützen kann?

Frage 2: Kann mir mal einer VM 86 Erlären?

Frage 3: Soll ich erst Speicherverwaltung P und V planen und implementieren oder erst multitasking?

Frage 4: Welche IPC Methode würdet ihr mir empfehlen?

Frage 5: Wann sollte ich VFS implementieren?

Programm Noob

PS: Bitte schreibt hier keine Scheiße.

[kevin]

Frage 1: Auf was muss ich achten, das ich später ohne Probleme 64 Bit unterstützen kann?

Vergiss das mit "ohne Probleme", das klappt ja schon bei der Architektur nicht, für die man im Moment schreibt.

Ansonsten eben die grundsätzlichen Regeln der Plattformunabhängigkeit. Plattformabhängige Teile in eigene Dateien auslagern, kein Assembler in plattformunabhängigen Teilen, die richtigen Datentypen verwenden (z.B. uintptr_t statt int, wenn ein Pointer reinsoll).

Frage 2: Kann mir mal einer VM 86 Erlären?

Ja, das Intel-Manual. Das Wiki und der tyndur-Source enthalten evtl. noch ein bisschen Informationen, um das zu veranschaulichen.

Frage 3: Soll ich erst Speicherverwaltung P und V planen und implementieren oder erst multitasking?

Um es mit meinem alten Mathelehrer zu sagen: Der eine mag lieber Vanilleeis, der andere lieber Schokoladeneis.

Frage 4: Welche IPC Methode würdet ihr mir empfehlen?

Lies dir einen von den langen Threads mit erik durch, da geht es immer nur um genau diese Frage. Wie die Länge dieser Threads schon vermuten lässt, gibt es keine kurze Antwort auf die Frage.

Frage 5: Wann sollte ich VFS implementieren?

Sobald du irgendwas mit Dateien machen willst.

PS: Bitte schreibt hier keine Scheiße.

Scheiße.

[Programm Noob]

Das Problem mit VM86 ist, das ich aus den Intel Manuals und dem Tyndursourcecode nicht Schlau werde. Ich fände es echt nett, wenn mir das mal einer erklären könnte.

Programm Noob

[kevin]

Was genau an VM86 ist denn nicht verständlich? Wenn du konkrete Fragen stellst, kann man vielleicht sogar helfen. Aber ein komplettes Tutorial mit Code zum Kopieren wird dir wahrscheinlich niemand mal eben schreiben.

[Programm Noob]

Wenn ich das VM Bit in den eflags aktiviere und den stack, so wie ere im Wiki beschrieben ist aufbaue, geht es nicht. es kommen nur fehler, welche weiß ich gerade nicht, dauert auch noch ein wenig, da ich gerade bei der gdt bin. Ein Tutorial wäre zwar schön, aber Code zum kopieren ist zwar schön zum ansehen, aber ich kopiere nicht mehr.

[XanClic]

Wenn ich das VM Bit in den eflags aktiviere

Ich hoffe nicht, dass das

Code: [Auswählen]

pushfd
pop eax
or eax,0x20000
push eax
popfdheißen soll, das wäre nämlich falsch (wie taljeth in #lost mal sagte, würde da wohl gar nichts passieren).

Man beachte, was im Wiki zum Stack steht: „Aufbau eines Stacks direkt vor dem iret zu einem VM86-Task:“ – will sagen, der einfachste Weg ist es, die ganzen für iret nötigen Sachen auf den Stack zu legen (was, steht ja im Artikel), dabei im entsprechenden eflags-Feld halt Bit 17 gesetzt haben und dann ein iret auszuführen.

Vielleicht sollte ich mal ins Wiki schreiben, dass „setzen“ nicht per „popfd laden“ heißt…

Auf was muss ich achten, das ich später ohne Probleme 64 Bit unterstützen kann?

1. dass du lieber „worauf“ benutzt und 2. dass du dir bewusst bist, dass vm86 nur bei i386 geht.


EDIT: Hab das jetzt ins Wiki geschrieben. Hoffentlich ist es jetzt klarer (wobei auch vorher niemand verboten hat, mal ins Manual zu schauen, wie es funktioniert).

[erik.vikinger]

Hallo,

hab ich die Schauze voll von diesen nicht funktionierdem kaputten zusammenkopiertem Code-Berg.

Weshalb hast Du dann damit erst angefangen?
Bei zusammen kopiertem Code kommt nur extrem selten was gescheites bei raus, falls Du dieses Forum aufmerksam verfolgst werden Dir etliche Beispiele dafür auffallen.

Deshalb rewrite ich NandOS und will einiges besser und ein paar Sachen voher besser planen.

Das kannst Du schon mal gleich vergessen. Bis man es schafft ein Projekt geradlinig von der Planung, über die Projektierung, durch die Implementierung zum Ziel zu bringen braucht man schon ein gehöriges Maß an Erfahrung (selbst langjährige Profis bekommen das nicht immer hin). Und das gilt in besonderem Maße für ein OS-Projekt! Du wirst mit hoher Wahrscheinlichkeit noch mehrere Versuche brauchen bis Du was "vorzeigbares" (also etwas für das man sich wenigstens nicht zu schämen braucht) zu Stande bringst. Lass Dich davon nicht entmutigen, aber es wäre falsch wenn wir Dir einen leichten Weg versprechen den es einfach nicht gibt.

Frage 1: Auf was muss ich achten, das ich später ohne Probleme 64 Bit unterstützen kann?

Schreibe "portablen" Code. Was das genau bedeutet wirst Du auch erst mit der Zeit lernen. Ich musste vieles davon auch erst auf die harte Tour lernen indem ich mit nicht-portablen Code gegen die Wand gebrettert bin. Du wirst Dir dabei mit Sicherheit den einen oder anderen blauen Fleck holen, viel Spaß damit.

Frage 2: Kann mir mal einer VM 86 Erlären?

Den brauchst Du noch nicht.

Frage 3: Soll ich erst Speicherverwaltung P und V planen und implementieren oder erst multitasking?

Eine bessere Antwort als die welche Dir taljeth gegeben hat gibt es einfach nicht!

Frage 4: Welche IPC Methode würdet ihr mir empfehlen?

Eine die Deinen Ansprüchen genügt und vom Schwierigkeitsgrad her Deinen Fähigkeiten entspricht! Wenn das nicht zusammenpasst musst Du an einem von beiden was ändern.
Der Relevante Punkt beim IPC ist wie die Aufträge dem Service zugestellt werden, da gibt es im wesentlichen 3 Möglichkeiten:

• aktives Abholen, dazu blockiert aber Dein Service oder Du hast mehrere Threads, die meisten OSe dürften das benutzen
• zustellen lassen wie UNIX-Signale, einfach zu implementieren aber leider mit einigen Nachteilen verbunden (für die klassischen Signale ist das Okay aber für intensiv genutztes IPC eher ungeeignet)
• zustellen lassen mit PopUp-Threads, hat meines Wissens nach noch nie jemand implementiert

Such Dir eine Variante aus (denke dabei an die 2 obigen Kriterien) und wenn Du konkrete Fragen hast kannst Du die gerne stellen.

Frage 5: Wann sollte ich VFS implementieren?

Unmittelbar bevor Du es benötigst. Bei einem Micro-Kernel-OS (ich vermute das Du eines schreiben möchtest sonst hättest Du nicht nach IPC gefragt) ist der VFS ein ganz normaler User-Mode-Prozess und kommt erst an die Reihe nachdem der Kernel schon mal einigermaßen gut läuft.

PS: Bitte schreibt hier keine Scheiße.

Na hör mal, was ist denn das für ein Ton? Schonmal vorsorglich rumpöbeln geht IMHO gar nicht, das kannst Du immer noch machen wenn Du wirklich unverschämte Antworten kriegen solltest. Außerdem hängt die Qualität der Antworten wohl auch erheblich von der Qualität Deiner Fragen ab!


Grüße
Erik

[Programm Noob]

Ich stellte mir gerade die Frage, ob ich mein eigenes Treiberinterfache weiterentwickeln soll, oder CDI implementieren soll.

Damit ich mich besser entscheiden kann, ein paar fragen bezüglich CDI.

Frage 1: Gibt es Probleme mit CDI unter 64 bit bzw. Hat schonmal einer CDI erfolgreich in einem 64 Bit OS eingesetzt?

Frage 2: Was für Treiber sind momentan in arbeit bzw. wie viele Treiber kommen so pro Monat dazu?

Ich hoffe ihr könnt mir diese beiden Fragen beantworten.

Programm Noob

[XanClic]

Frage 1: Gibt es Probleme mit CDI unter 64 bit bzw. Hat schonmal einer CDI erfolgreich in einem 64 Bit OS eingesetzt?

Pedigree unterstützt CDI und es gibt davon wohl auch eine 64-Bit-Version, ob beides zusammen existiert, weiß ich nicht – da ich aber nie Beschwerden von pcmattman über CDI und amd64 gehört habe (und solch eine Unterstützung ist schon angedacht, wenn es z. B. ein Flag für cdi_mem_alloc gibt (CDI_MEM_DMA_4G), das dafür sorgt, dass Speicher unterhalb von 4 GB zurückgegeben wird, dann ist das schon ein deutliches Zeichen dafür), wird das schon der Fall sein.

Was für Treiber sind momentan in arbeit bzw. wie viele Treiber kommen so pro Monat dazu?

Wirklich in direkter Arbeit wären wohl aktuell das CDI.video-Interface und der erste Treiber dafür, VBE. Allgemein in Arbeit (kann aber noch eine Weile dauern, und das ist wohl nicht zuletzt auch meine Schuld) wären CDI.audio (und hier ein AC97-Treiber) sowie CDI.usb (das kann allerdings wirklich noch lange dauern, wenn es überhaupt realisiert wird).
Ansonsten arbeite ich noch theoretisch an einem tulip-Treiber (eine Netzwerkkarte), aber andere neue Treiber fallen mir im Moment nicht ein – wobei mir auch kein Treiber einfällt, den ich sonst gern hätte. Mit tulip wäre noch die andere Netzwerkkarte abgedeckt, die ich habe (neben rtl8139), und mit AC97 könnte ich zumindest einen Computer versorgen (HD Audio ist wohl etwas schwieriger, ich weiß gar nicht, ob es da überhaupt offizielle Spezifikationen gibt).

Tjo, wie viele pro Monat dazukommen… Ich muss ehrlich sagen, dass ich, seitdem ich CDI mitverfolge, keinen neuen Treiber gesehen habe. Will sagen, derzeit tendiert die Zahl gegen 0 (wobei ich, wie gesagt, auch keinen Treiber wirklich vermisse, an dem nicht bereits so halb gearbeitet würde).

[kevin]

Nicht, dass die Zahl irgendeine Bedeutung hätte, aber... Der erste Commit im CDI-Repo ist von Dezember 2007, also 33 Monate. Ich zähle im Moment 11 Treiber. Macht pro Monat einen Dritteltreiber.

Zu den Treibern, die halbwegs aktiv in Arbeit sind, würde wohl FAT auch noch zählen.

[Programm Noob]

Ok dann scheint es wohl unter x86-64 zu gehen, aber das nur so wenige Treiber entwickelt werden...
Ich glaube ich schreibe einfach einen Wrapper, um CDI Treiber, in dem von mir bisher nur auf dem Papier entwickeltem Treiberinterface zu nutzen.

Programm Noob

[kevin]

Wenn du auch einen Treiber schreibst, sind es schonmal mehr.

Ich glaube aber auch, dass du erstens unterschätzt, wie viel Arbeit ein Treiber machen kann, und zweitens überschätzt, wie viele Treiber man in der Praxis tatsächlich braucht.

[Programm Noob]

Ich weiß ein Treiber zu schreiben ist ne menge arbeit, ich schreibe momentan parallel zu entwicklung der beiden neuen Kernel an Floppy Treiber für NandOS.

Naja man benötigt nicht umbedingt viele Treiber auf einmal. Aber rum auf portabel zu seon benötigt man viele Treiber. Wir benötigen bei uns im Haus 5 verschiedene Netzwerkkartentreiber und 3 Verschiedene Soundtreiber. Dazu kommen dann noch die Treiber für Maus, Tastatur, RS232, Parallele Schnittstelle, ATA, SATA,  Floppy, USB,Fireware, Grafik, Drucker, Webcam usw.Also Treiber braucht man schon recht viele.

Wenn ich CDI implementiere, dann werde ich den einen oder anderen Treiber für CDI schreiben, sollte ich jedoch nur einen Wrapper schreiben, werde ich gucken wie es mit einem Wrapper in die andere Richtung aussieht.

Programm Noob

[Tederian]

Die Frage ist welche Treiber du überhaupt brauchst.
Webcam bringt dir herzlichst wenig ohne VGA, Drucker auch nur wenig.
Grafik haben meist keine offenen Dokumentationen, und auch wenn sie es haben sind diese alles andere als gut verständlich.
Besser an der OS-Architektur herumtüfteln als die Zeit mit Treiber zu verschwenden

[kevin]

Ich weiß ein Treiber zu schreiben ist ne menge arbeit, ich schreibe momentan parallel zu entwicklung der beiden neuen Kernel an Floppy Treiber für NandOS.

Floppy ist relativ harmlos. Okay, die Hardware kann störrisch sein, aber sie ist halbwegs vernünftig dokumentiert und fast jeder hat einen Floppytreiber, so dass man auch Code vergleichen kann, wenn was nicht tut.

Spaßiger wird das ganze schon, wenn man Treiber für eine Hardware schreibt, wenn man nur Dokumentation zu "ähnlicher" Hardware hat. Und selbst mit vernünftiger Dokumentation schwer sind Dateisystemtreiber, die nicht ab und zu das Dateisystem kaputtmachen.

Wenn ich CDI implementiere, dann werde ich den einen oder anderen Treiber für CDI schreiben, sollte ich jedoch nur einen Wrapper schreiben, werde ich gucken wie es mit einem Wrapper in die andere Richtung aussieht.

Wenn du dir den Wrapper sparst, kannst du die Zeit besser darin investieren, CDI zu verbessern.

[Programm Noob]

Klar Webcam bringt noch nichts, aber es sollte nur ne auflistung von Treibern sein, die irgendwann mal benötigt werden.
Für Grafik gibts VESA. Um CDI zu verbessern müsste ich mich bis ins tiefste innere von CDI reinarbeiten. Ich werde mir es nochmal überlegen.

Programm Noob

[kevin]

CDI ist eine Schnittstelle. Da gibt es nicht viel inneres.

[bluecode]

(HD Audio ist wohl etwas schwieriger, ich weiß gar nicht, ob es da überhaupt offizielle Spezifikationen gibt).

Gibt es, siehe intel.com

[erik.vikinger]

Hallo,


Zum CDI hätte ich auch noch ein paar Fragen (wo wir gerade dabei sind) :

Wie finden eigentlich die Treiber usw. zu einander?
Ich stelle mir das so vor das der PCI-Treiber eine Reihe an Geräten findet (enumeriert), diesen passende Ressourcen zuweist (was beim PC ja schon durchs BIOS erledigt wurde) und dann anhand von Vendor/Device-ID einen spezifischen Treiber oder anhand vom Class-Code einen generischen Treiber lädt (hier ist die Reihenfolge wichtig). Dieser Treiber müsste vom PCI-Treiber für das gefundene Gerät gestartet werden (was auch mehrmals passieren kann) und sich dann ans CDI "anmelden" können (eben auch mehrmals, falls mehrere gleiche Geräte vorhanden sind). In diesem Zusammenhang sind mir die Funktionen cdi_run_drivers() und cdi_driver_register() noch ziemlich unklar.

Wo werden eigentlich die gefundenen Blockdevices den einzelnen Dateisystemen zugeordnet oder in Partitionen gesplittet?
Gerade für die Dateisysteme vermisse ich eine Funktion die einem Dateisystemtreiber die ersten paar Sektoren einer Partition oder eines Blockdevices (falls nicht partitioniert) übergibt damit das Dateisystem erst einmal prüfen kann ob es sich überhaupt dafür zuständig fühlt und dann vom CDI eine neue Instanz gestartet wird.

Wie kann sich der IP-Stack an CDI anmelden?
Zumindest bei einem Micro-Kernel-OS ist er ja nicht direkt Bestandteil des eigentlichen OS selber. Obwohl man auch sagen könnte das bei einem richtigen Micro-Kernel-OS der Kernel noch nicht mal weiß das CDI überhaupt existiert.

Bei den PCI-Geräten ist immer nur ein IRQ erlaubt, warum?
Könnte man die IRQs nicht auch als Ressource betrachten, so wie Speicherbereiche und I/O-Port-Bereiche?
Mir ist klar das in aktuellen PCs kaum ein Gerät mehr als einen IRQ benutzt aber viele (wie AHCI) sind zu mehr fähig.


Ein bisschen mehr Beschreibung des "Drumherum" wäre nicht schlecht.
Wenn CDI nur eine Sammlung von Funktionsprototypen ist dann ist sein Nutzwert IMHO noch recht gering, es sollte auch ein Konzept existieren wie man CDI benutzen muss damit es einem auch wirklich was hilft.

Gibt es, siehe intel.com

Hast Du auch die Seite gelesen? Da gibt es einen Abschnitt der mit "Implementation of the High Definition Audio Specification requires a license from Intel. ..." anfängt. Die Frage ist: bezieht sich das nur auf HW-Implementierungen oder sind da auch SW-Implementierungen, Treiber aber auch Emulatoren, mit inbegriffen? Ich glaube zwar nicht das Intel irgendwelchen Hobby-OS-Devern eine Horde Anwälte aufhetzen würde, nur weil die einen (rudimentären) Treiber für das HD-Audio programmieren, aber mal nachfragen sollte man eventuell schon. Bei den anderen Spezifikationen aus dem Hause Intel ist das etwas klarer formuliert.


Grüße
Erik

[FreakyPenguin]

Wie finden eigentlich die Treiber usw. zu einander?
Ich stelle mir das so vor das der PCI-Treiber eine Reihe an Geräten findet (enumeriert), diesen passende Ressourcen zuweist (was beim PC ja schon durchs BIOS erledigt wurde) und dann anhand von Vendor/Device-ID einen spezifischen Treiber oder anhand vom Class-Code einen generischen Treiber lädt (hier ist die Reihenfolge wichtig). Dieser Treiber müsste vom PCI-Treiber für das gefundene Gerät gestartet werden (was auch mehrmals passieren kann) und sich dann ans CDI "anmelden" können (eben auch mehrmals, falls mehrere gleiche Geräte vorhanden sind). In diesem Zusammenhang sind mir die Funktionen cdi_run_drivers() und cdi_driver_register() noch ziemlich unklar.

In der cdi_driver-Struktur des Treibers wird ein Bus angegeben, hier halt PCI. Sobald der Treiber dann initialisiert wurde, ruft die CDI-Implementierung die init_device-Methode des Treibers auf, für jedes der PCI-Geräte (die noch keinen Treiber haben). Und falls dem Treiber ein Gerät gefällt, erstellt er eine device-Struktur und gibt diese zurück an die CDI-Implementierung.
run_drivers gehört nicht mehr dazu, wenn ich mich richtig erinnere. Und ich glaube die driver_register-Funktionen sind auch veraltet, das geht neu mit dem CDI_DRIVER-Makro.

Wo werden eigentlich die gefundenen Blockdevices den einzelnen Dateisystemen zugeordnet oder in Partitionen gesplittet?
Gerade für die Dateisysteme vermisse ich eine Funktion die einem Dateisystemtreiber die ersten paar Sektoren einer Partition oder eines Blockdevices (falls nicht partitioniert) übergibt damit das Dateisystem erst einmal prüfen kann ob es sich überhaupt dafür zuständig fühlt und dann vom CDI eine neue Instanz gestartet wird.

Das zuordnen der Dateisystemen zum Blockgerät hat nichts mit CDI zu tun, das ist Sache der Implementierung.

Wie kann sich der IP-Stack an CDI anmelden?
Zumindest bei einem Micro-Kernel-OS ist er ja nicht direkt Bestandteil des eigentlichen OS selber. Obwohl man auch sagen könnte das bei einem richtigen Micro-Kernel-OS der Kernel noch nicht mal weiß das CDI überhaupt existiert.

Der IP-Stack meldet sich garnicht an CDI an. Ich würde das eher so implementieren, dass sich die CDI/net-Implementierung halt beim Netzwerk-Stack anmeldet, und die entsprechenden Geräte meldet, und dann natürlich auch die Pakete durchstellt.

Bei den PCI-Geräten ist immer nur ein IRQ erlaubt, warum?
Könnte man die IRQs nicht auch als Ressource betrachten, so wie Speicherbereiche und I/O-Port-Bereiche?
Mir ist klar das in aktuellen PCs kaum ein Gerät mehr als einen IRQ benutzt aber viele (wie AHCI) sind zu mehr fähig.

Weil bisher niemand mehr gebraucht hat? Es dürfte ja relativ offensichtlich sein, dass CDI bis jetzt eher nicht auf vollständigkeit sondern eher auf Einfachheit ausgerichtet ist.

Ein bisschen mehr Beschreibung des "Drumherum" wäre nicht schlecht.
Wenn CDI nur eine Sammlung von Funktionsprototypen ist dann ist sein Nutzwert IMHO noch recht gering, es sollte auch ein Konzept existieren wie man CDI benutzen muss damit es einem auch wirklich was hilft.

CDI ist halt die Definition einer Schnittstelle, dazu gehören halt die Funktions-Prototypen und die Typen. Sinn des ganzen ist ja genau, dass die Schnittstelle nicht vorschreibt wie sie implementiert/benutzt werden _muss_, um die nötige Flexibilität zu erhalten sie problemlos unter verschiedenen Betriebssystem-Typen laufen zu lassen.