25. April 2024, 05:30
Beiträge anzeigen
Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.
Ich hoffe das wird spätestens Montag erledigt sein.
Dass das VFS in den Micro-Kernel gehört würde ich persönlich dann doch eher verneinen, mein Micro-Kernel soll nicht mal wissen das es überhaupt Dateien gibt (wozu auch? mir fällt da absolut kein Grund ein), aber ich schätze mit dieser Meinung bin ich hier wohl eindeutig in der Unterzahl.
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
[wiki=QEMU]QEMU-Seite[/wiki]Ein Cronjob damit einzurichten sollte eigentlich machbar sein. FreakyPenguin?
Callbackbasiert wäre, dass du nur einen Thread hast. Um Requests abzusetzen, rufst du eine Funktion auf, die diesen Request abschickt und direkt zurückkehrt. Wenn der Request irgendwann fertig ist, ruft sie einen Callback auf. Während der Request läuft und der Kontrollfluss wieder in der CDI-Lib ist, kannst du aber schonmal den nächsten Request absetzen. Vorteile und Nachteile sind genau umgekehrt: Du kommst ohne Locking zurecht, weil immer nur ein Stück Code gleichzeitig läuft, aber der Code wird zerrissen und statt einem zusammenhängenden Ablauf bekommst du eine State Machine. Performancemäßig schätze ich ist die Callbackvariante wahrscheinlich auch ein bisschen besser. Aber ich bin mir nicht sicher, ob ich damit beispielsweise einen Dateisystemtreiber schreiben wollte...
Also zum ausprobieren ob der Treiber passt, hätte ich jetzt einfach fs_init() aufgerufen, und wenns klappt hast du deine Instanz und sonst halt nicht. Wenn du unter "neue Instanz gestartet", erst das laden des Dateisystem-Treibers verstehst könnte das eventuell nicht ganz einfach werden. Da es bei den Dateisystemen nicht einfach ein standardisiertes Feld haben, wo wir nachsehen können um welches Dateisystem es sich handelt.ZitatGerade 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.Hm, ja. Patches willkommen.
Wie finden eigentlich die Treiber usw. zu einander?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.
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?Das zuordnen der Dateisystemen zum Blockgerät hat nichts mit CDI zu tun, das ist Sache der Implementierung.
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?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.
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?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.
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.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.
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.
