Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: Programm Noob am 02. September 2010, 22:47
-
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.
-
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.
-
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
-
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.
-
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.
-
Wenn ich das VM Bit in den eflags aktiviere
Ich hoffe nicht, dass das
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).
-
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
-
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
-
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).
-
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.
-
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
-
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.
-
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
-
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 :P
-
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. :)
-
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
-
CDI ist eine Schnittstelle. Da gibt es nicht viel inneres. ;)
-
(HD Audio ist wohl etwas schwieriger, ich weiß gar nicht, ob es da überhaupt offizielle Spezifikationen gibt).
Gibt es, siehe intel.com (http://www.intel.com/standards/hdaudio/)
-
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 (http://www.intel.com/standards/hdaudio/)
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
-
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.
-
Soweit ich informiert bin, ist das Problem nicht der HD-Audio-Chip, sondern die daran angebastelte Hardware (Codecs von Intel/Realtek/..., HD-Audio-Modem, ...) und deren Dokumentation ist eher dürftig oder nur beschränkt nutzbar. Daran hustet ja auch das ALSA-Projekt rum, wenn in verschiedenen Rechnern die gleichen Codecbausteine verschieden angeschlossen sind.
Das CDI scheint mir relativ PCI-zentrisch zu sein, eine Abstraktion für Bussysteme fehlt mir irgendwie komplett. Wie wird das dann mit verschachtelten Bussystemen geregelt? (PCI-PCI-Bridges, CardBus und/oder PCMCIA, MMIO-Busse oder den ganzen µC-Kram wie SPI, I²C, ...) Funktioniert ein CDI-rtl8139-Treiber auch dann noch, wenn die rtl8139 über eine MMIO-Schnittstelle angebunden ist oder läuft der Treiber dann nur mit PCI-Hardware?
Gruß
-
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).
Das deckt sich so ungefähr mit meiner Vorstellung. Automatisches Starten von Treibern hat noch niemand gebastelt, insofern ist dieser Teil nur Theorie. Was vor allem dazu fehlt, ist eine Möglichkeit, beim Bauen der Treiber auch gleich eine Datenbank aufzubauen, welche Vendor/Device-IDs (oder was auch immer) zu welchem Treiber gehören.
Im Moment läuft es in der Praxis so, dass man die Treiber von Hand startet (bzw. vor allem in Monolithen einfach immer alle startet) und die dann alle noch nicht "vergebenen" Geräte anschauen und akzeptieren oder eben auch nicht.
In diesem Zusammenhang sind mir die Funktionen cdi_run_drivers() und cdi_driver_register() noch ziemlich unklar.
Hm, ist cdi_run_drivers() nicht längst tot? Und cdi_driver_register() macht auch nicht sinnvolles mehr und wird wohl in absehbarer Zeit das Schicksal mit ersterem teilen.
Wo werden eigentlich die gefundenen Blockdevices den einzelnen Dateisystemen zugeordnet oder in Partitionen gesplittet?
OS-spezifischer Code, der über cdi_storage_device_init() aufgerufen wird.
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.
Hm, ja. Patches willkommen. :)
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.
Normal eher umgekehrt, Netzwerkkarten melden sich beim IP-Stack an. Es gibt ja nicht "das CDI" als zentrale Instanz, sondern CDI ist eine Bibliothek, die im Kontext von jedem einzelnen Treiber läuft. cdi_net_device_init() wäre wiederum die richtige Stelle für solche Sachen.
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 es genau ein Feld für den IRQ im Configspace gibt, und das bildet die struct ab. :)
Falls es mal einen Einsatzzweck gibt, habe ich natürlich nichts gegen eine entsprechende Erweiterung. Aber ich möchte die Schnittstellen jetzt nicht overengineeren ohne dass es jemals benutzt wird. Solche Erweiterungen kann man dann einbauen, wenn man sie braucht.
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.
Dokumentation schreibt sich leider auch nicht von selbst. Mit etwas Hilfe würde es wahrscheinlich schneller gehen, aber außer von mir habe ich schon lang keine Dokumentationspatches mehr gesehen.
-
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.
Hm, ja. Patches willkommen. :)
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.
-
Das CDI scheint mir relativ PCI-zentrisch zu sein, eine Abstraktion für Bussysteme fehlt mir irgendwie komplett. Wie wird das dann mit verschachtelten Bussystemen geregelt? (PCI-PCI-Bridges, CardBus und/oder PCMCIA, MMIO-Busse oder den ganzen µC-Kram wie SPI, I²C, ...) Funktioniert ein CDI-rtl8139-Treiber auch dann noch, wenn die rtl8139 über eine MMIO-Schnittstelle angebunden ist oder läuft der Treiber dann nur mit PCI-Hardware?
Auch hier wieder - das kann man gern dann näher anschauen, wenn man es wirklich braucht. Wenn wir erstmal etwas designt hätten, das für jede denkbare Hardwarekombination passt, hätten wir in zehn Jahren noch nichts (und vor allem nichts korrektes, weil ich ohne echte Erfahrung mit einer bestimmten Sache auch kein ordentliches Interface dafür hinbekomme).
Wenn du dich darum kümmern willst, kannst du ja mal einen Treiber anpacken, der auf verschiedenen Bussen läuft.
-
Och lieber nicht. :-P
Linux hat ja auch keine Bussystem-Abstraktion, deswegen gibt es ja "ne" (ISA), "ne2" (MCA), "ne2k-pci" (PCI), "pcnet_cs" (PCMCIA), die dann gemeinsame common-code-Kernelmodule (z.B. 8390.o) benutzen.
NetBSD abstrahiert sowas, deswegen gibt es da nur einen Treiber für alle diese Geräte.
Grüßle
-
Dachte ich mir schon, dass wieder gekniffen wird, wenn es drum geht, sich die Händer selber dreckig zu machen. ;)
-
Magst du mir derweil die Hochfrequenztechnik näher erläutern? (charakt. Impedanz, Widerstandsbeläge, Lastreflexionskoeffizient, ...)
Außerdem hab ich bisher kein Betriebssystem und keinen Treiber geschrieben. Da kneif ich lieber und schreibe anderswo dummes Zeugs. :-P
-
Hallo,
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).
Das deckt sich so ungefähr mit meiner Vorstellung.
Das ist sehr schön. ;)
Aber leider scheint sich das nicht mit CDI zu decken, oder habe ich was übersehen?
Wenn die Doku deutlich Out-of-Date ist dann Okay.
Automatisches Starten von Treibern hat noch niemand gebastelt, insofern ist dieser Teil nur Theorie.
Das ist aber bedauerlich. Ich hätte gedacht das dies der einfachste Weg ist und er deshalb von tyndur benutzt wird.
Was vor allem dazu fehlt, ist eine Möglichkeit, beim Bauen der Treiber auch gleich eine Datenbank aufzubauen, welche Vendor/Device-IDs (oder was auch immer) zu welchem Treiber gehören.
Ja, das wäre ein nützliches Feature. Da könnte man vielleicht im make-File der Treiber was passendes tun. So eine Datenbank (ein simple Liste würde wohl reichen) könnte auch gleich noch eine SHA256-Summe der Treiber-Binary enthalten und würde so für etwas mehr Vertrauen in die Treiber sorgen. Für ein kleines Hobby-OS sollten erst mal ein paar generische Treiber (SATA/AHCI, USB-Host-Controller + USB-HID und USB-Mass-Storage, RS232, GraKa, Floppy) und ein paar spezifische Teiber (verschiedene LAN-Controller) völlig reichen.
Im Moment läuft es in der Praxis so, dass man die Treiber von Hand startet (bzw. vor allem in Monolithen einfach immer alle startet) und die dann alle noch nicht "vergebenen" Geräte anschauen und akzeptieren oder eben auch nicht.
Meinst Du das jeder Treiber angetriggert wird und dieser dann alle übrigen PCI-Geräte prüft ob die ihm gefallen? Wer hat sich das denn ausgedacht?
Das erinnert mich an sehr altes Linux wo z.B. der NE2000-Treiber alle möglichen I/O-Ports durchprobiert hat ob es da irgendwo eine ISA-NE2000 gibt, selbst wenn es gar keine NE2000 im PC gibt.
Hm, ist cdi_run_drivers() nicht längst tot? Und cdi_driver_register() macht auch nicht sinnvolles mehr und wird wohl in absehbarer Zeit das Schicksal mit ersterem teilen.
Also ist die Doku wirklich massiv Out-of-Date.
Wo werden eigentlich die gefundenen Blockdevices den einzelnen Dateisystemen zugeordnet oder in Partitionen gesplittet?
OS-spezifischer Code, der über cdi_storage_device_init() aufgerufen wird.
Wieso ist das OS-spezifisch? Wie die Partitions-Tabelle aufgebaut ist liegt doch nicht am OS und auch das Erkennen des benutzten Dateisystems ist IMHO für alle OSe gleich.
Wie kann sich der IP-Stack an CDI anmelden? ...
Normal eher umgekehrt, Netzwerkkarten melden sich beim IP-Stack an.
Das ist klar, aber beim CDI melden sich ja die Netzwerkkarten beim CDI an und daher hatte ich gefragt.
Es gibt ja nicht "das CDI" als zentrale Instanz, sondern CDI ist eine Bibliothek, die im Kontext von jedem einzelnen Treiber läuft. cdi_net_device_init() wäre wiederum die richtige Stelle für solche Sachen.
Es ist also Aufgabe meiner CDI-Implementierung dafür zu sorgen das die Netzwerkkarten auch wirklich zum IP-Stack kommen.
Bei den PCI-Geräten ist immer nur ein IRQ erlaubt, warum? ....
Weil es genau ein Feld für den IRQ im Configspace gibt, und das bildet die struct ab.
Aha.
Aber ich möchte die Schnittstellen jetzt nicht overengineeren ohne dass es jemals benutzt wird. Solche Erweiterungen kann man dann einbauen, wenn man sie braucht.
ACK. Bei mir wird wohl schon ne einfache Serielle Schnittstelle 3 IRQs haben (Sende-Puffer leer, Empfangs-Puffer voll und sonstiges wie Framing-Error), aber das liegt auch daran das ich mit IRQs nicht sparsam sein muss (mein IRQ-Controller soll theoretisch 4034 IRQs können, in der Praxis werden wohl erstmal 64 IRQs reichen).
Dokumentation schreibt sich leider auch nicht von selbst. Mit etwas Hilfe würde es wahrscheinlich schneller gehen, aber außer von mir habe ich schon lang keine Dokumentationspatches mehr gesehen.
Das ist nur zu wahr, aber es können auch nur Leute helfen die davon wirklich Ahnung haben.
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.
Hm, ja, einfach ist das tatsächlich nicht. Entweder man hat den Treiber schon geladen (und grundinitialisiert) damit man von ihm auch irgendeine Art von Probe-Funktion nutzen kann oder man müsste irgendetwas vorgelagertes bauen damit nur die wirklich benötigten Dateisystemtreiber auch tatsächlich geladen werden (und damit Speicher verbrauchen). Mit "neue Instanz" meine ich nicht zwangsläufig eine neue Programm-Instanz (bei einem Micro-Kernel), es könnte auch sein das man vom Dateisystem-Treiber einfach nur z.B. eine neue IPC-Schnittstelle anfordert über die dann das neu gemountete Dateisystem benutzt werden kann.
Ich will nicht überheblich klingen aber einen besonders hohen Nutzwert scheint mir CDI nicht zu haben, ich muss ja trotzdem noch sehr viel selber designen und implementieren. Ich finde irgendwie keine Argumente warum mein OS eben CDI benutzen sollte. Gerade auf einem Micro-Kernel-OS (wo der Kernel doch von all dem gar nichts mitbekommt) wäre es schon sehr schön wenn es auch etwas mehr Konzept und generischen Code geben würde. Ja, ich weiß das schreibt sich nicht von selber.
Soweit ich informiert bin, ist das Problem nicht der HD-Audio-Chip, sondern die daran angebastelte Hardware (Codecs von Intel/Realtek/..., HD-Audio-Modem, ...) und deren Dokumentation ist eher dürftig oder nur beschränkt nutzbar. Daran hustet ja auch das ALSA-Projekt rum, wenn in verschiedenen Rechnern die gleichen Codecbausteine verschieden angeschlossen sind.
So genau habe ich die HDA-Spec nicht gelesen. Mir ist schon aufgefallen das die sich eher um die PCI-Seite kümmert aber ich dachte das die AD-DA-Wandler dann immer auf die selbe Art angeschlossen werden.
Das CDI scheint mir relativ PCI-zentrisch zu sein, eine Abstraktion für Bussysteme fehlt mir irgendwie komplett.
Wo ist den da das Problem? Alles außer PCI ist am aussterben. Die Nachfolger PCI-Express oder Hypertransport sind für die SW-Sicht (was Config-Space usw. angeht) 100% kompatibel. Auf meiner Plattform will ich sogar soweit gehen das nichts kein PCI-Device sein darf, also jede RS232-Schnittstelle usw. als eigenständiges PCI-Gerät erscheint (und damit von der PCI-Enumeration und PCI-Treiber-Verwaltung erfasst wird). Auf dem PC würde ich das so lösen das man die Geräte-Liste vom PCI-Treiber nimmt und sie um die nicht-PCI Standard-Geräte der PC-Plattform (RS232, Floppy-Controller, Tastatur-Controller) ergänzt so das alles nach PCI-Gerät aussieht.
Wie wird das dann mit verschachtelten Bussystemen geregelt? (PCI-PCI-Bridges
Also bei PCI-2-PCI-Bridges ist das gar kein Problem, das bleiben PCI-Geräte und hinter einer PCI-2-ISA-Bridge hängen eben ISA-Geräte (da gibt es eh nur noch RS232, Floppy und Tastatur).
CardBus und/oder PCMCIA
Ist de-facto ausgestorben bzw. für Hobby-OSe unrelevant. Für manche PCMCIA-HW hat man ja schon unter Linux (oder gar Windows) Probleme einen geeigneten Treiber zu finden, wieso sollte ein kleines Hobby-OS da besser sein?
MMIO-Busse oder den ganzen µC-Kram wie SPI, I²C, ...)
Gibt es das in handelsüblichen PCs? Bis auf den I²C zum auslesen des Monitors über die GraKa und der CPU-Temperatur übers Main-Board (was beides für einfache Hobby-OSe wohl nicht relevant ist) wird das alles nicht benötigt.
Funktioniert ein CDI-rtl8139-Treiber auch dann noch, wenn die rtl8139 über eine MMIO-Schnittstelle angebunden ist oder läuft der Treiber dann nur mit PCI-Hardware?
Wer hat schon einen RTL8139 auf einer Nicht-PCI-Hardware? Gibt es das überhaupt, hab da bei Realtek nichts gefunden. Mal davon abgesehen das ich persönlich von der Benutzung von Realtek-Hardware grundsätzlich abrate.
Grüße
Erik
-
Automatisches Starten von Treibern hat noch niemand gebastelt, insofern ist dieser Teil nur Theorie.
Das ist aber bedauerlich. Ich hätte gedacht das dies der einfachste Weg ist und er deshalb von tyndur benutzt wird.
Treiber manuell starten ist nochmal deutlich einfacher, wenn vielleicht auch nicht ganz so zufriedenstellend.
Im Moment läuft es in der Praxis so, dass man die Treiber von Hand startet (bzw. vor allem in Monolithen einfach immer alle startet) und die dann alle noch nicht "vergebenen" Geräte anschauen und akzeptieren oder eben auch nicht.
Meinst Du das jeder Treiber angetriggert wird und dieser dann alle übrigen PCI-Geräte prüft ob die ihm gefallen? Wer hat sich das denn ausgedacht?
Du kannst irgendwie keinen Code kritisieren, ohne gleich die Person zu kritisieren, oder? ;)
Es ist eine einfache Lösung ohne größere Nachteile. Beim Laden eines Treibers dauert es mal ein paar Takte länger, ja. Kann ich verschmerzen. Löst sich automatisch, wenn das mit der Treiberliste implementiert ist und PCI (oder welche Instanz auch immer die Geräte verwaltet) weiß, an wen es das Gerät abgeben muss.
Das erinnert mich an sehr altes Linux wo z.B. der NE2000-Treiber alle möglichen I/O-Ports durchprobiert hat ob es da irgendwo eine ISA-NE2000 gibt, selbst wenn es gar keine NE2000 im PC gibt.
Denk nochmal über diesen Vergleich nach, vielleicht merkst du selber, dass er nichtmal ansatzweise passt.
Also ist die Doku wirklich massiv Out-of-Date.
Wohin schaust du denn? http://lpt.tyndur.org/cdi/ sollte aktuell sein.
Wieso ist das OS-spezifisch? Wie die Partitions-Tabelle aufgebaut ist liegt doch nicht am OS und auch das Erkennen des benutzten Dateisystems ist IMHO für alle OSe gleich.
Es ist aber auch nicht Teil des Treibers, für den CDI eine Schnittstelle ist. Ich habe auch schon daran gedacht, einen portablen Teil der Implementierung gleich im CDI-Repo zu haben (und Code für Partitionen wäre da ein guter Kandidat), aber der schreibt sich auch nicht von selbst.
Ich will nicht überheblich klingen aber einen besonders hohen Nutzwert scheint mir CDI nicht zu haben, ich muss ja trotzdem noch sehr viel selber designen und implementieren. Ich finde irgendwie keine Argumente warum mein OS eben CDI benutzen sollte.
CDI liefert dir auch nicht ein halbes OS, sondern nur ein paar Treiber und eine Schnittstelle, wie sich die Treiber in die infrastruktur deines OS einbinden lassen. Es schreibt dir nicht vor, wie deine Infrastruktur aussehen muss - da hat vermutlich sowieso jedes OS seine eigenen Vorlieben.
Gerade auf einem Micro-Kernel-OS (wo der Kernel doch von all dem gar nichts mitbekommt) wäre es schon sehr schön wenn es auch etwas mehr Konzept und generischen Code geben würde. Ja, ich weiß das schreibt sich nicht von selber.
Richtig. Du darfst gern deinen Teil beisteuern, wenn du Ideen hast, wie man Dinge einfacher lösen könnte oder auf welche Bereiche "man" CDI ausdehnen sollte. Einfach nur erwarten, dass andere die ganze Arbeit machen, funktioniert nicht.
-
Erik, boote mal ein NetBSD auf deinem PC, dann stellst du relativ schnell fest, dass da unglaublich viele seltsame Bussysteme auftauchen. Gut, ein Großteil davon ist virtuell und der Abstraktion geschuldet, aber so kann man halt wunderbar Bussysteme verschachteln.
Z.B. der Intel HDA hat kann mehrere Geräte verwalten (Codecs verschiedener Hersteller für Audiogeräte, Modems verschiedener Hersteller, ...), das ist vom Prinzip her ein Bussystem. Genauso wie das I²C der Grafikkarte ein Bussystem ist (wenn auch nur ein Gerät - der Monitor - dran hängt). Und wenn du eine solche Abstraktion für Bussysteme allgemein hast, kannst du halt quasi-kostenlos deine PCI-USB-Bridge als neuen Bus betrachten.
Wenn man das nicht macht, behandelt man den I²C der Grafikkarte halt im Grafiktreiber, die USB-Busse (ein Hub führt zu einem neuen USB-Bus, außerdem hat man mehrere USB-Busse im System) behandelt man im USB-Stack, jeder Hardwaretreiber steuert den Bus privat an. Geht auch - Windows und Linux machen das so.
CardBus erscheint dem System gegenüber die PCI mit ein paar Eigenschaften, PCMCIA wie ein komplett neuer ISA-Bus mit dynamischer Resourcenzuweisung. Was MMIOs angeht, so steuern sich einige Grafikkarten darüber an, d.h. du legst mit den VGA-Standardregistern ein paar Sachen fest und greifst auf erweiterten Kram über physische Speicherzugriffe jenseits des RAMs zu. Die PCI-Konfigurationsregister sind eigentlich auch MMIOs...
Der rtl8139 ist ein Baustein, den kannst du auf jede Netzwerkkarte setzen, wenn du möchtest... auf PCI und USB gibt es ihn definitiv, alles andere ist eher unwahrscheinlich.
Grüßle
-
Hallo,
Treiber manuell starten ist nochmal deutlich einfacher, wenn vielleicht auch nicht ganz so zufriedenstellend.
Was meinst Du eigentlich mit "manuell" starten? Ich hatte das so verstanden das tyndur einfach alle Treiber startet, diese sich beim CDI anmelden und dann alle angetriggert werden damit sich jeder Treiber was passendes aus der Geräte-Liste aussuchen darf. Das dabei einige Treiber leer ausgehen (und damit nur unnötig Speicher kosten) ist eigentlich logisch. Als denn offensichtlichsten Weg hätte ich jetzt gedacht das man im PCI-Treiber die Geräte-Liste einmal durcharbeitet und jedes Gerät mit einer erstmal hardcodierten Treiber-Liste, in der eben Vendor/Device-IDs oder Class-Codes stehen, durcharbeitet. So würde ich das zumindest machen wenn ich noch keinen automagischen Driver-Loader für Plug&Play-Hardware hab.
Meinst Du das jeder Treiber angetriggert wird und dieser dann alle übrigen PCI-Geräte prüft ob die ihm gefallen? Wer hat sich das denn ausgedacht?
Du kannst irgendwie keinen Code kritisieren, ohne gleich die Person zu kritisieren, oder? ;)
Den zweiten Satz hätte ich mir wirklich verkneifen sollen. Sorry, ich muss wohl auf jeden Fall noch etwas an den Filtermechanismen zwischen meinen wirren Gedanken und meinen Fingern arbeiten.
Es ist eine einfache Lösung ohne größere Nachteile.
Also ich würde bei dieser Lösung weder von "einfach" noch von "ohne größere Nachteile" schreiben. Der offensichtlichste Nachteil ist das Treiber übrig bleiben können, also geladen werden ohne das es tatsächlich Hardware für sie gibt. Anders kann ich mir bei dem Konzept auch keine Live-CD vorstellen die auf einem noch unbekannten PC funktionieren soll.
Löst sich automatisch, wenn das mit der Treiberliste implementiert ist und PCI (oder welche Instanz auch immer die Geräte verwaltet) weiß, an wen es das Gerät abgeben muss.
Ich finde das wird sich nicht einfach so in Wohlgefallen auflösen, zwischen "Treiber prüft jedes vorhandene Gerät ob er zuständig ist" und "PCI-System selektiert anhand klar definierter Kriterien welcher Treiber für ein bestimmtes Gerät geladen werden soll" ist IMHO schon ein erheblicher konzeptioneller Unterschied.
Das erinnert mich an sehr altes Linux wo z.B. der NE2000-Treiber alle möglichen I/O-Ports durchprobiert hat ob es da irgendwo eine ISA-NE2000 gibt, selbst wenn es gar keine NE2000 im PC gibt.
Denk nochmal über diesen Vergleich nach, vielleicht merkst du selber, dass er nichtmal ansatzweise passt.
Ich finde schon das der Vergleich recht gut passt. Der Treiber schaut sich verschiedene Geräte an und prüft ob sie ihm gefallen, bei tyndur wird eben eine Geräte-Liste durchgearbeitet (ein LAN-Treiber könnte sich so auch USB-Host-Controller anschauen nur weil der dafür zuständige Treiber erst nach ihm kommt und wenn es gar keine passende LAN-Karte gibt dann war der Treiber umsonst aktiv) und bei ISA greift der Treiber mehrmals (eventuell immer) ins Leere um zu schauen wo überall Geräte sein könnten für die er zuständig wäre.
Also ist die Doku wirklich massiv Out-of-Date.
Wohin schaust du denn? http://lpt.tyndur.org/cdi/ sollte aktuell sein.
Auch ins Wiki. Die Doxygen-Seite ist ganz nett aber ich würde mir schon irgendwo eine Beschreibung aus dem konzeptionellen Blickwinkel wünschen. Alls Nachschlagewerk während des Schreibens von Code ist die Seite sicher sehr nützlich aber leider nicht um erst mal einen Einstig in die Materie zu finden.
Wieso ist das OS-spezifisch? Wie die Partitions-Tabelle aufgebaut ist liegt doch nicht am OS und auch das Erkennen des benutzten Dateisystems ist IMHO für alle OSe gleich.
Es ist aber auch nicht Teil des Treibers, für den CDI eine Schnittstelle ist. Ich habe auch schon daran gedacht, einen portablen Teil der Implementierung gleich im CDI-Repo zu haben (und Code für Partitionen wäre da ein guter Kandidat), aber der schreibt sich auch nicht von selbst.
Das ist ein guter Gedanke. Mir ist klar das sich das alles nicht von selbst erledigt. CDI ist quasi ein Gratis-Angebot und das kann ich entweder annehmen oder es lassen, aber einen Anspruch auf Fähigkeiten die mir zusagen hab ich natürlich nicht. Solange CDI nur eine Ansammlung von Header-Dateien ist ist es zwar eine gute Ideen- und Kopier-Vorlage aber eben keine Library die man haben will und für die man auch bereit ist ein paar (konzeptionelle) Nachteile in Kauf zu nehmen. Das ist zumindest meine persönliche Meinung
CDI liefert dir auch nicht ein halbes OS, sondern nur ein paar Treiber und eine Schnittstelle, wie sich die Treiber in die infrastruktur deines OS einbinden lassen.
Das CDI kein OS liefert ist klar und auch gewünscht, schließlich wollen die meisten hier ihr OS selber nach eigenen Vorstellungen entwickeln (da bin ich ganz sicher keine Ausnahme). Das mit den Treibern und der Schnittstelle kann ich noch nicht ganz glauben, dafür ist meiner persönlichen Meinung nach noch zu vieles an das jeweilige OS anzupassen. Für mein OS würde ich z.B. gerne die Dateisystemtreiber und die USB-Sachen (wenn es da mal etwas gibt) übernehmen, aber ob das überhaupt geht kann ich momentan noch gar nicht beurteilen (zur Zeit bin ich da eher skeptisch). Dafür hab ich einfach noch deutlich zu wenig Einblick in die Wirkmechanismen die sich hinter CDI verbergen, die sind nämlich quasi gar nicht dokumentiert.
Gerade auf einem Micro-Kernel-OS (wo der Kernel doch von all dem gar nichts mitbekommt) wäre es schon sehr schön wenn es auch etwas mehr Konzept und generischen Code geben würde. Ja, ich weiß das schreibt sich nicht von selber.
Richtig. Du darfst gern deinen Teil beisteuern, wenn du Ideen hast, wie man Dinge einfacher lösen könnte oder auf welche Bereiche "man" CDI ausdehnen sollte. Einfach nur erwarten, dass andere die ganze Arbeit machen, funktioniert nicht.
Ich bin gerne bereit an den Konzepten und Ideen von CDI mitzuarbeiten, schon aus Eigennutz heraus den wenn ich von CDI einige Treiber übernehmen könnte würde mir das sicher sehr helfen, aber dazu müsste ich einen besseren Einblick in CDI haben. Das sich CDI nicht von alleine weiterentwickelt ist mir klar. Aus meiner Sicht stellt sich die Frage ob ich besser fahre wenn ich an CDI mithelfe um etwas zu bekommen das mir gut nützt auch wenn es nicht perfekt zu meinem OS passt oder ob ich lieber was eigenes aufziehe das mich eventuell mehr Arbeit kostet aber dafür auch perfekt zu meinem OS passt. Aus meiner Sich wäre da z.B. das durchreichen von Speicher zwischen den einzelnen Treiber-Schichten ein relevanter Aspekt. Ermöglicht mir CDI eine durchgängige Zero-Copy-Methodik?
Erik, boote mal ein NetBSD auf deinem PC, ....
Das weiß ich, ich frage mich aber worin da konkret ein Nutzwert besteht. Klar die NE2000-Schnittstelle gab es tatsächlich für ISA, PCI, PCMCIA und wohl noch andere Busse (aber definitiv nicht für USB), der RTL8139 ist aber ganz klar ein PCI-LAN-Controller (schon weil er Busmaster ist und im normalen RAM liegende Verwaltungsstrukturen benutzt) den es nur auf PCI-basierten Bussen gibt und nicht auf ISA, USB oder anderen Bussen.
Auch der HDA bietet an seinen South-Port eine Art Bus aber es gibt dazu kein anderes Äquivalent also keine Notwendigkeit das eigenständig zu abstrahieren.
Das einzigste was man in dieser Hinsicht mit PCI vergleichen kann ist USB. USB ist natürlich ein Bus und es gibt auch viele Parallelen zu PCI aber auch viele Unterschiede (USB hat keine Adressräume wie Speicher oder I/O-Ports und keine IRQs) und es gibt keine identischen Geräte für beide Busse. Ein RS232 UART, z.B. 16550 (wie er als PCI-Gerät existiert), gibt es nicht für USB, ebenso wie die RS232-Controller für USB nichts mit dehnen für PCI gemein haben, das sind 2 völlig verschiedene Geräte (mit völlig verschiedenen Ansteuerungs-Philosophien) auch wenn sie nach außen gleich aussehen.
Für I²C lohnt es sich auf jeden Fall das in einer Library zu verpacken die dann vom Graphikkarten-Treiber ebenso wie vom Mainboard-Treiber benutzt wird aber mehr ist da nicht. Geräte die an einem I²C-Bus hängen benutzen eine völlig andere Ansteuerung als vergleichbare PCI-Geräte oder USB-Geräte (nebst dessen das es wohl kaum die selbe Klasse von Geräten für I²C und PCI in einem PC gibt).
Was MMIOs angeht, ...
Das ist kein Bus sondern einfach etwas das auf allen anderen Plattformen außer PC der einzige Weg ist um mit Hardware-Geräten zu kommunizieren (und auch bei x86 schon längst den Normalfall darstellt).
Die PCI-Konfigurationsregister sind eigentlich auch MMIOs
Das darf man so machen, die PCI-Express-Spezifikation empfiehlt das sogar und bei Hypertransport ist bereits in der Spezifikation ein Speicher-Bereich exklusiv dafür vorgesehen, aber es gibt dazu keine Pflicht. Aus PCI-Sicht ist und bleibt der Config-Adress-Space ein zusätzlicher eigenständiger Adressraum und wie die PCI(-Express)-Root-Bridge den nach oben hin anbietet ist ganz ausdrücklich außerhalb der PCI(-Express)-Spezifikation.
Grüße
Erik
-
Was meinst Du eigentlich mit "manuell" starten? Ich hatte das so verstanden das tyndur einfach alle Treiber startet, diese sich beim CDI anmelden und dann alle angetriggert werden damit sich jeder Treiber was passendes aus der Geräte-Liste aussuchen darf.
Alle Treiber starten könnte man zwar theoretisch machen, machen wir aber nicht. Im Moment muss der Benutzer entweder in der servmgr-Konfiguration eintragen, was er haben will, oder es den Treiber von Hand auf der Shell starten. In der Praxis haben wir sowieso nur die fertigen Images, für die der passende Treibersatz so gut wie feststeht - das Floppyimage hat floppy und fat gebraucht, das Plattenimage ata und ext2 und die Live-CD ata, iso9660, ramoverlay und ext2. Das einzige, was sich wirklich unterscheidet, sind die Netzwerkkarten und dafür läuft beim ersten Start erstmal das Setupprogramm, das die Netzwerkkonfiguration abfragt (und den Treiber anhand der PCI-ID versucht zu erkennen, hartkodiert) und fürs nächste Mal abspeichert.
Aber wollen wir jetzt wirklich diskutieren, was die bessere Notlösung ist, wenn man das richtige noch nicht implementiert hat? ;)
Löst sich automatisch, wenn das mit der Treiberliste implementiert ist und PCI (oder welche Instanz auch immer die Geräte verwaltet) weiß, an wen es das Gerät abgeben muss.
Ich finde das wird sich nicht einfach so in Wohlgefallen auflösen, zwischen "Treiber prüft jedes vorhandene Gerät ob er zuständig ist" und "PCI-System selektiert anhand klar definierter Kriterien welcher Treiber für ein bestimmtes Gerät geladen werden soll" ist IMHO schon ein erheblicher konzeptioneller Unterschied.
Schon. Aber die Treiberliste ist ja auch eine erhebliche konzeptionelle Änderung, also kann die das auch lösen. ;)
Letztendlich geht es ja nur darum, dass CDI dem Treiber nicht mehr alle PCI-Geräte anbieten soll, sondern nur noch diejenigen, die auch wirklich zu ihm passen. Der Treiber selber müsste sich dazu theoretisch gar nicht ändern, nur die CDI-Implementierung von tyndur. (Praktisch gesehen wird sich der Treiber doch ein bisschen ändern müssen, damit man nämlich aus seinem Code die Datenbank generieren kann).
Ich finde schon das der Vergleich recht gut passt. Der Treiber schaut sich verschiedene Geräte an und prüft ob sie ihm gefallen, bei tyndur wird eben eine Geräte-Liste durchgearbeitet (ein LAN-Treiber könnte sich so auch USB-Host-Controller anschauen nur weil der dafür zuständige Treiber erst nach ihm kommt und wenn es gar keine passende LAN-Karte gibt dann war der Treiber umsonst aktiv) und bei ISA greift der Treiber mehrmals (eventuell immer) ins Leere um zu schauen wo überall Geräte sein könnten für die er zuständig wäre.
Nur, dass der ISA-Treiber nicht zuverlässig sagen kann, was für ihn da ist und was nicht. Er muss halt probieren, ob die Hardware antwortet wie erwartet, oder?
Auch ins Wiki. Die Doxygen-Seite ist ganz nett aber ich würde mir schon irgendwo eine Beschreibung aus dem konzeptionellen Blickwinkel wünschen. Alls Nachschlagewerk während des Schreibens von Code ist die Seite sicher sehr nützlich aber leider nicht um erst mal einen Einstig in die Materie zu finden.
Hm, Doku schreiben ist schwer. Kannst du mir Hinweise geben, welche Information dir auf der Doxygen-Seite konkret fehlt? Dann kann ich mal schauen, ob ich dazu was zusammengeschrieben bekomme. Für mich ist das alles offensichtlich, das macht es so schwer, es vernünftig zu beschreiben.
Solange CDI nur eine Ansammlung von Header-Dateien ist ist es zwar eine gute Ideen- und Kopier-Vorlage aber eben keine Library die man haben will und für die man auch bereit ist ein paar (konzeptionelle) Nachteile in Kauf zu nehmen. Das ist zumindest meine persönliche Meinung
Naja, CDI ist zwar eine Handvoll Headerdateien, aber dazu gibt es auch noch ein paar Treiber, die magischerweise anfangen zu funktionieren, wenn man diese Header implementiert. ;)
Darin sehe ich schon einen gewissen Wert. Wenn ich daran denke, dass beispielsweise der ext2-Treiber ein gutes halbes Jahr gebraucht hat (und das war der dritte Anlauf, wenn man die Nicht-CDI-Vorgänger mitzählt), dann spare ich mir diese Zeit gern.
Das mit den Treibern und der Schnittstelle kann ich noch nicht ganz glauben, dafür ist meiner persönlichen Meinung nach noch zu vieles an das jeweilige OS anzupassen. Für mein OS würde ich z.B. gerne die Dateisystemtreiber und die USB-Sachen (wenn es da mal etwas gibt) übernehmen, aber ob das überhaupt geht kann ich momentan noch gar nicht beurteilen (zur Zeit bin ich da eher skeptisch). Dafür hab ich einfach noch deutlich zu wenig Einblick in die Wirkmechanismen die sich hinter CDI verbergen, die sind nämlich quasi gar nicht dokumentiert.
An welchen Punkten hast du denn Zweifel, dass sie sich mit deinem OS vertragen? Ich kann mir eigentlich keine grundsätzlichen Inkompatibilitäten vorstellen. Und falls doch, müssen wir sie halt fixen. CDI ist in Code gegossener Pragmatismus. ;)
Aus meiner Sich wäre da z.B. das durchreichen von Speicher zwischen den einzelnen Treiber-Schichten ein relevanter Aspekt. Ermöglicht mir CDI eine durchgängige Zero-Copy-Methodik?
Noch nicht, ist aber geplant und in Reichweite. Eigentlich müsste man nur alle verwendeten Speicherbereiche konsequent von void*/size_t auf cdi_mem_area umstellen, dann sollte sich das als Zero Copy implementieren lassen. Will ich irgendwann auch bei tyndur machen, wenn die wichtigeren Baustellen mal erledigt sind.
-
Erik, boote mal ein NetBSD auf deinem PC, ....
Das weiß ich, ich frage mich aber worin da konkret ein Nutzwert besteht. Klar die NE2000-Schnittstelle gab es tatsächlich für ISA, PCI, PCMCIA und wohl noch andere Busse (aber definitiv nicht für USB), der RTL8139 ist aber ganz klar ein PCI-LAN-Controller (schon weil er Busmaster ist und im normalen RAM liegende Verwaltungsstrukturen benutzt) den es nur auf PCI-basierten Bussen gibt und nicht auf ISA, USB oder anderen Bussen.
Nur, dass der Chip diese Möglichkeiten nutzt, heißt nicht, dass er nicht auch auf anderen Bussen eingesetzt werden kann - ich hatte sowohl einen ne2000-Ableger (rtl8029), als auch eine rtl8139 für USB schon in der Hand.
Auch der HDA bietet an seinen South-Port eine Art Bus aber es gibt dazu kein anderes Äquivalent also keine Notwendigkeit das eigenständig zu abstrahieren.
Das nicht unbedingt, aber eine vernünftige Abstraktion kann (muss aber nicht) für die Implementation von Modems und/oder Codecs hilfreich sein. Bei NetBSD steht Wiederverwertbarkeit halt ganz oben, den anderen Systemen ist es relativ egal, wenn man mal ein paar Codezeilen im Treiber duplizieren muss.
Das einzigste was man in dieser Hinsicht mit PCI vergleichen kann ist USB. USB ist natürlich ein Bus und es gibt auch viele Parallelen zu PCI aber auch viele Unterschiede (USB hat keine Adressräume wie Speicher oder I/O-Ports und keine IRQs) und es gibt keine identischen Geräte für beide Busse. Ein RS232 UART, z.B. 16550 (wie er als PCI-Gerät existiert), gibt es nicht für USB, ebenso wie die RS232-Controller für USB nichts mit dehnen für PCI gemein haben, das sind 2 völlig verschiedene Geräte (mit völlig verschiedenen Ansteuerungs-Philosophien) auch wenn sie nach außen gleich aussehen.
Begrenzt auch nach innen, wenn nämlich ein UART16550 über einen Controllerbaustein an den USB angeflanscht wurde. Da trifft man die ganzen Register wieder, auch wenn sie ganz woanders stecken. Gleiches für die Druckerschnittstellen, beileibe nicht jede taugt nur zum Drucken.
Für I²C lohnt es sich auf jeden Fall das in einer Library zu verpacken die dann vom Graphikkarten-Treiber ebenso wie vom Mainboard-Treiber benutzt wird aber mehr ist da nicht. Geräte die an einem I²C-Bus hängen benutzen eine völlig andere Ansteuerung als vergleichbare PCI-Geräte oder USB-Geräte (nebst dessen das es wohl kaum die selbe Klasse von Geräten für I²C und PCI in einem PC gibt).
I²C hat keine Enumeration und Adressen haben nur 7 Bit. Damit ist I²C eher vergleichbar mit ISA als mit PCI, soweit ist das richtig. Trotzdem kann es ein vollwertiges Bussystem sein - in vielen µCs ist es das auch. Auf dem PC ist das natürlich alles Haarspalterei, richtig.
Was MMIOs angeht, ...
Das ist kein Bus sondern einfach etwas das auf allen anderen Plattformen außer PC der einzige Weg ist um mit Hardware-Geräten zu kommunizieren (und auch bei x86 schon längst den Normalfall darstellt).
Lässt sich aber prima als Bus abstrahieren, wäre dann vergleichbar mit I²C und SPI.
Es gibt Vorteile für den Aufwand. Inwieweit sich aber Aufwand:Nutzen auszahlen, kann ich nicht einschätzen. Unter OS/2 2.1 hat jeder Treiber für PCI-Geräte eine eigene PCI-Bibliothek mitzubringen, da das OS von PCI nichts weiß. Genau diese Verfahrensweise wird heute oft praktiziert - alles, was nicht PCI ist (oder einfach zu PCI gemacht werden kann), wird als Userspace-Lib verpackt.
Zumal CDI ja nun wirklich keine Altlasten zu beachten hat, daher finde ich das etwas schade. Der OS-Implementeur muss dann ja auch nur einzelne Bussysteme implementieren (PCI), wenn ihm der Rest egal ist. Leider gibt das CDI nicht her, was daran liegt, dass CDI eigentlich "nur" eine dokumentierte Treiberschnittstelle von tyndur ist.
Schönen Gruß,
Sebastian
-
Zumal CDI ja nun wirklich keine Altlasten zu beachten hat, daher finde ich das etwas schade. Der OS-Implementeur muss dann ja auch nur einzelne Bussysteme implementieren (PCI), wenn ihm der Rest egal ist. Leider gibt das CDI nicht her, was daran liegt, dass CDI eigentlich "nur" eine dokumentierte Treiberschnittstelle von tyndur ist.
Woran es wirklich liegt ist folgendes: Ich kann ein paar Wochen damit verbringen, ordentliche Abstraktionen einzubauen und mich in diverse Bussysteme einlesen, für die ich nie einen Treiber implementieren werde. Oder ich baue in einer halben Stunde genau das, was ich gerade brauche und womit ich mich einigermaßen auskenne und nutze den Rest der Zeit für andere Baustellen, die tatsächlich heute Auswirkungen haben.
Wenn jemand die Schnittstelle entsprechend umbauen will, gerne. Aber ich bin nicht derjenige.
-
Hallo,
Alle Treiber starten könnte man zwar theoretisch machen, machen wir aber nicht. ....
Aha, es wird also eine manuelle Vorauswahl getroffen damit nicht völlig unnütze Treiber geladen werden.
Aber wollen wir jetzt wirklich diskutieren, was die bessere Notlösung ist, wenn man das richtige noch nicht implementiert hat? ;)
Nein, streiten müssen wir nicht. Es hat mich eben nur gewundert wie man auf so eine Idee kommt, ich hätte versucht den hartcodierten Code (vom Setup-Programm) ins PCI-System zu integrieren und dieses dafür sorgen zu lassen das für jedes gefundene PCI-Gerät ein passender Treiber gestartet wird.
Löst sich automatisch, wenn das mit der Treiberliste implementiert ist und PCI (oder welche Instanz auch immer die Geräte verwaltet) weiß, an wen es das Gerät abgeben muss.
Ich finde das wird sich nicht einfach so in Wohlgefallen auflösen, zwischen "Treiber prüft jedes vorhandene Gerät ob er zuständig ist" und "PCI-System selektiert anhand klar definierter Kriterien welcher Treiber für ein bestimmtes Gerät geladen werden soll" ist IMHO schon ein erheblicher konzeptioneller Unterschied.
Schon. Aber die Treiberliste ist ja auch eine erhebliche konzeptionelle Änderung, also kann die das auch lösen. ;)
Du darfst mich gerne einen Pessimisten nennen aber ich finde das siehst Du etwas zu optimistisch. Aber wir werden es ja bestimmt noch erleben.
Letztendlich geht es ja nur darum, dass CDI dem Treiber nicht mehr alle PCI-Geräte anbieten soll, sondern nur noch diejenigen, die auch wirklich zu ihm passen.
Ich würde es anders formulieren: "CDI sollte nur die Treiber laden für die es auch tatsächlich Geräte gibt und dann denn Treiber eben genau diese Geräte geben".
Der Treiber selber müsste sich dazu theoretisch gar nicht ändern, nur die CDI-Implementierung von tyndur. (Praktisch gesehen wird sich der Treiber doch ein bisschen ändern müssen, damit man nämlich aus seinem Code die Datenbank generieren kann).
Klingt ziemlich gut, ich hoffe Du hast damit auch recht.
Nur, dass der ISA-Treiber nicht zuverlässig sagen kann, was für ihn da ist und was nicht. Er muss halt probieren, ob die Hardware antwortet wie erwartet, oder?
Nur das der CDI-Treiber nicht zuverlässig sagen kann, was für ihn da ist und was nicht. Er muss halt probieren, ob der übergebene Hardware-Descriptor so aussieht wie erwartet, oder? ;)
Hm, Doku schreiben ist schwer.
Wie wahr!
Kannst du mir Hinweise geben, welche Information dir auf der Doxygen-Seite konkret fehlt? Dann kann ich mal schauen, ob ich dazu was zusammengeschrieben bekomme.
Mir fehlt vor allen etwas Überblick und Konzept, es ist nicht förderlich gleich Funktions-Prototypen zu sehen ohne zu wissen was damit eigentlich gemacht werden soll. Es müssten auch die Überlegungen die dazu geführt haben das CDI so ist wie es ist erläutert werden damit man sich nicht ständig fragt "Haben die nicht an .... gedacht?".
Für mich ist das alles offensichtlich, das macht es so schwer, es vernünftig zu beschreiben.
Genau das ist das Problem.
Naja, CDI ist zwar eine Handvoll Headerdateien, aber dazu gibt es auch noch ein paar Treiber, die magischerweise anfangen zu funktionieren, wenn man diese Header implementiert. ;)
Hängen diese Treiber wirklich nur von den CDI-Headerdateien ab und haben sonst keine Abhängigkeiten?
Darin sehe ich schon einen gewissen Wert. Wenn ich daran denke, dass beispielsweise der ext2-Treiber ein gutes halbes Jahr gebraucht hat (und das war der dritte Anlauf, wenn man die Nicht-CDI-Vorgänger mitzählt), dann spare ich mir diese Zeit gern.
Eben genau darum geht es mir ja auch, wenn ich Eure Dateisystemtreiber übernehmen könnte wäre das für mich ein echter Gewinn. Was ich mich frage ist wie hoch ist der Preis, um das besser beurteilen zu können müsste ich aber schon deutlich mehr über die Konzepte hinter CDI wissen.
An welchen Punkten hast du denn Zweifel, dass sie sich mit deinem OS vertragen?
Welche Ansprüche werden z.B. an die IPC-Mechanismen gestellt? Du weißt das ich da schon etwas von den üblichen/ausgetrampelten Pfaden abweichen will.
Wie gut sind die Treiber reentrant? Es könnten doch problemlos mehrere Applikationen gleichzeitig mit Dateien arbeiten wollen.
Ich kann mir eigentlich keine grundsätzlichen Inkompatibilitäten vorstellen.
Das CDI grundsätzlich nicht auf meine Plattform geht glaube ich auch nicht, ich bin mir nur nicht ganz sicher ob ich mit CDI auch die Konzepte umsetzen kann die mir vorschweben (z.B. Zero-Copy und Reentranz).
Eigentlich müsste man nur alle verwendeten Speicherbereiche konsequent von void*/size_t auf cdi_mem_area umstellen, dann sollte sich das als Zero Copy implementieren lassen.
Warum? Was ist das Problem mit void*/size_t bzw. was macht cdi_mem_area besser? Für mein Konzept hatte ich mir auch nur void*/size_t vorgestellt (siehst Du ja an meinem IPC-Konzept) und ich sehe da derzeit auch keine Probleme.
der RTL8139 ist aber ganz klar ein PCI-LAN-Controller (schon weil er Busmaster ist und im normalen RAM liegende Verwaltungsstrukturen benutzt) den es nur auf PCI-basierten Bussen gibt und nicht auf ISA, USB oder anderen Bussen.
Nur, dass der Chip diese Möglichkeiten nutzt, heißt nicht, dass er nicht auch auf anderen Bussen eingesetzt werden kann
Doch genau das heißt es! Weder ISA-Geräte noch USB-Geräte (und erst recht nicht I²C-Geräte) können als Bus-Master auf den physischen Haupt-RAM zugreifen! Die Konzepte die der RTL8139 verwendet machen ihn definitiv PCI-Only. Das einzigste was geht sind die PCI-Ableger, also PCI-Express, PCI-X, Hyper-Transport oder auch AGP, dafür könnte man einen RTL8139 kompatiblen Chip entwickeln der mit exakt dem selben Treiber läuft. Aber da diese Busse für die SW eh nach PCI aussehen lohnt sich da keine Bus-Abstraktion.
ich hatte sowohl einen ne2000-Ableger (rtl8029), als auch eine rtl8139 für USB schon in der Hand.
Das halte ich für extrem unwahrscheinlich. Da stand vielleicht die selbe Nummer drauf, damit weniger technik-kundige Menschen da ein Gefühl von Vertrautheit entwickeln, aber der benutzte Chip und auch der Treiber hat ganz sicher nichts mit dem ISA- oder PCI-Original gemeinsam außer der Schnittstelle nach Außen (LAN-Buchse) und zum OS (es sind ja alles Ethernet-Treiber).
Auch der HDA bietet an seinen South-Port eine Art Bus aber es gibt dazu kein anderes Äquivalent also keine Notwendigkeit das eigenständig zu abstrahieren.
Das nicht unbedingt, aber eine vernünftige Abstraktion kann (muss aber nicht) für die Implementation von Modems und/oder Codecs hilfreich sein.
Ich denke das wird sich kaum lohnen. Ich kenne mich mit den Audio-Codes nicht sonderlich aus aber ich glaube nicht das man z.B. die Treiber (falls man die überhaupt als eigenständige Module entwickelt hat) für AC97-Codecs auch für HDA-Codecs benutzen kann, ich denke da gibt es zu viele konzeptionelle Unterschiede.
Bei NetBSD steht Wiederverwertbarkeit halt ganz oben
Das ist zweifelsohne ein ehrenwertes Ziel aber man sollte sich überlegen wie lohnend das überhaupt ist. Mal von NE2000 abgesehen kenne ich nichts für das sich das wirklich lohnen würde. Für ein Hobby-OS (wo die Programmierer ihre kostbare und knappe Zeit lieber anderen Dingen widmen) dürfte selbst die tollste Bus-Abstraktion absolut gar keinen Vorteil bringen. Wenn da wirklich jemand NE2000 unterstützen möchte dann kompiliert er den Treiber lieber mehrfach und verwendet immer die selbe Code-Basis, nur mit ein paar bus-spezifischen Extras versehen.
wenn nämlich ein UART16550 über einen Controllerbaustein an den USB angeflanscht wurde
Warum sollte jemand so einen Blödsinn tun? Für USB-Geräte verwendet man ganz andere Ansteuerungs-Paradigmen! USB basiert auf seinen Pipes und PCI auf Adressräumen, das sind 2 völlig verschiedene Welten. Überlege doch mal selber wie man mit den USB-Mechanismen die 8 UART-Register ansteuern sollte, das wäre extrem umständlich. Die existierenden USB-RS232-Chips haben wirklich nichts mit dem 16550 gemein, ebenso wie die USB-HID-Class nichts mit dem AT-Tastatur-Controller gemein hat.
I²C hat keine Enumeration und Adressen haben nur 7 Bit. Damit ist I²C eher vergleichbar mit ISA als mit PCI, soweit ist das richtig.
I²C hat auch keine I/O-Ports, IRQs oder DMA-Leitungen also ist I²C auch nicht mit ISA vergleichbar. Da haben ja ISA und PCI mehr Gemeinsamkeiten.
Trotzdem kann es ein vollwertiges Bussystem sein
Das bestreitet doch niemand! Aber es gibt eben keine Gemeinsamkeiten mit PCI und auch keine identischen Geräte für beide Busse so das es sich eben auch nicht lohnt zu versuchen generische Treiber für beide zu programmieren.
Was MMIOs angeht, ...
Das ist kein Bus sondern einfach etwas das auf allen anderen Plattformen außer PC der einzige Weg ist um mit Hardware-Geräten zu kommunizieren (und auch bei x86 schon längst den Normalfall darstellt).
Lässt sich aber prima als Bus abstrahieren, wäre dann vergleichbar mit I²C und SPI.
Memory-Mapped-I/O bedeutet das die Steuerregister für eine Hardware im normalen Speicher-Adressraum liegen und nicht in einem extra I/O-Adressraum, das hat wirklich nichts mit irgendwelchen Bussystemen zu tun sondern mit der Art wie die CPU die Adressräume betrachtet.
Es gibt Vorteile für den Aufwand. Inwieweit sich aber Aufwand:Nutzen auszahlen, kann ich nicht einschätzen.
Für ein Hobby-OS dürfte sich das mit ziemlicher Sicherheit nicht auszahlen und selbst für ein OS wie Linux glaube ich nicht das dieser erhebliche Aufwand einen nennenswerten Nutzen bringt.
Unter OS/2 2.1 hat jeder Treiber für PCI-Geräte eine eigene PCI-Bibliothek mitzubringen, da das OS von PCI nichts weiß.
Das ist natürlich Mist, PCI ist seit 20 Jahren das Bus-Konzept in Computern (auch auf anderen Plattformen, nicht nur bei x86). Klar spielt PCI bei 8 Bit Mikrocontrollern keine Rolle, dafür ist dort I²C und SPI deutlich verbreiteter, aber das ist auch eine völlig andere Welt.
Genau diese Verfahrensweise wird heute oft praktiziert - alles, was nicht PCI ist (oder einfach zu PCI gemacht werden kann), wird als Userspace-Lib verpackt.
Daran ist meiner Meinung nach auch absolut nichts auszusetzen, alle relevanten Bussysteme sind wie PCI also können sie auch wie PCI behandelt werden. Die einzigste richtige Parallel-Welt dazu ist USB und dort gibt es auch parallel eine passende Infrastruktur. Was dann noch übrig bleibt (sowas wie die AC97- oder HDA-Busse für die Codecs) sind kleine Inseln die auch so behandelt werden können.
Leider gibt das CDI nicht her
CDI bietet das was man auf einem handelsüblichen PC der letzten 15 Jahre eben braucht und das ist PCI. Alles andere lohnt sich nicht (wie z.B. der I²C-bassierende SMB auf den Mainboards) oder kann als PCI dargestellt werden (wie z.B. die paar Standard-Geräte die noch auf ISA basieren). Daher schließe ich mich in diesem Punkt taljeths Meinung an.
Grüße
Erik
-
Letztendlich geht es ja nur darum, dass CDI dem Treiber nicht mehr alle PCI-Geräte anbieten soll, sondern nur noch diejenigen, die auch wirklich zu ihm passen.
Ich würde es anders formulieren: "CDI sollte nur die Treiber laden für die es auch tatsächlich Geräte gibt und dann denn Treiber eben genau diese Geräte geben".
Wenn's dir so besser gefällt. Ist auch nur eine andere Formulierung für dieselbe Idee.
Nur, dass der ISA-Treiber nicht zuverlässig sagen kann, was für ihn da ist und was nicht. Er muss halt probieren, ob die Hardware antwortet wie erwartet, oder?
Nur das der CDI-Treiber nicht zuverlässig sagen kann, was für ihn da ist und was nicht. Er muss halt probieren, ob der übergebene Hardware-Descriptor so aussieht wie erwartet, oder? ;)
Wenn ich die Vendor/Device-ID auslese und vergleiche, passiert in der Regel nichts böses. Wenn ich dagegen in irgendeinen Port einen Wert schreibe, um mal zu schauen, was zurückkommt, dann kann alles mögliche passieren...
Kannst du mir Hinweise geben, welche Information dir auf der Doxygen-Seite konkret fehlt? Dann kann ich mal schauen, ob ich dazu was zusammengeschrieben bekomme.
Mir fehlt vor allen etwas Überblick und Konzept, es ist nicht förderlich gleich Funktions-Prototypen zu sehen ohne zu wissen was damit eigentlich gemacht werden soll. Es müssten auch die Überlegungen die dazu geführt haben das CDI so ist wie es ist erläutert werden damit man sich nicht ständig fragt "Haben die nicht an .... gedacht?".
Du sollst ja auch nicht gleich die Funktionsprototypen anschauen, sondern beispielsweise die Beschreibung des Core-Moduls (was ja auf der Hauptseite verlinkt ist). Natürlich kann man da noch mehr machen, aber ich bin mir nicht sicher, ob ich weiß, was genau.
Naja, CDI ist zwar eine Handvoll Headerdateien, aber dazu gibt es auch noch ein paar Treiber, die magischerweise anfangen zu funktionieren, wenn man diese Header implementiert. ;)
Hängen diese Treiber wirklich nur von den CDI-Headerdateien ab und haben sonst keine Abhängigkeiten?
Plus ein paar von CDI mehr oder weniger genau festgelegte Sachen aus libc-Headern wie Stringfunktionen oder malloc/free. Steht auch in dieser Doxygen-Doku und ist von der Hauptseite verlinkt.
An welchen Punkten hast du denn Zweifel, dass sie sich mit deinem OS vertragen?
Welche Ansprüche werden z.B. an die IPC-Mechanismen gestellt? Du weißt das ich da schon etwas von den üblichen/ausgetrampelten Pfaden abweichen will.
IPC ist ein Implementierungsdetail von CDI auf deinem OS. Die Schnittstellen müssen für einen Monolithen, der alles im Kernel laufen lässt, genauso gut funktionieren wie für deinen Mikrokernel mit spezieller IPC.
Wie gut sind die Treiber reentrant? Es könnten doch problemlos mehrere Applikationen gleichzeitig mit Dateien arbeiten wollen.
Deine Applikationen gehen doch wohl nicht direkt zum FS-Treiber, sondern zu irgendeinem Cache?
Das Thema Parallelität ist aber noch unausgegoren. Da muss sich auf jeden Fall noch irgendwas ändern. Im Moment ist alles synchron und Nebenläufigkeit ist verboten. Bevor man das ändert, muss man sich aber erstmal klar werden, welches Konzept man verfolgen will (grundsätzliche Optionen sind callbackbasiert oder threadbasiert).
Das CDI grundsätzlich nicht auf meine Plattform geht glaube ich auch nicht, ich bin mir nur nicht ganz sicher ob ich mit CDI auch die Konzepte umsetzen kann die mir vorschweben (z.B. Zero-Copy und Reentranz).
Damit es perfekt mit deinen Konzepten zusammenpasst, wirst du wahrscheinlich an der einen oder anderen Stelle ausbessern müssen, falls diese Sachen nicht zufällig mit den Bedürfnissen eines anderen OS übereinstimmen, für das schon optimiert worden ist. Aber bevor du das machst, bekommst du immerhin schonmal was, was überhaupt funktioniert.
Eigentlich müsste man nur alle verwendeten Speicherbereiche konsequent von void*/size_t auf cdi_mem_area umstellen, dann sollte sich das als Zero Copy implementieren lassen.
Warum? Was ist das Problem mit void*/size_t bzw. was macht cdi_mem_area besser? Für mein Konzept hatte ich mir auch nur void*/size_t vorgestellt (siehst Du ja an meinem IPC-Konzept) und ich sehe da derzeit auch keine Probleme.
Hm, ich weiß gar nicht, inwiefern das bei deinem Konzept überhaupt nötig ist. In tyndur würden wir dort drin beispielsweise noch die SHM-ID speichern, wenn das ganze über Shared Memory weitergegeben worden ist.
Allgemein ist cdi_mem_area etwas mehr als nur void*/size. Es kann neben der virtuellen auch die physische Adresse enthalten (die Treiber ja gelegentlich brauchen), und zwar jeweils nicht unbedingt als eine einzelne Adresse, sondern als scatter/gather-Liste. Die Konvertierung auf dieses Modell ist aber nicht abgeschlossen.
-
Hallo,
Letztendlich geht es ja nur darum, dass CDI dem Treiber nicht mehr alle PCI-Geräte anbieten soll, sondern nur noch diejenigen, die auch wirklich zu ihm passen.
Ich würde es anders formulieren: "CDI sollte nur die Treiber laden für die es auch tatsächlich Geräte gibt und dann denn Treiber eben genau diese Geräte geben".
Wenn's dir so besser gefällt. Ist auch nur eine andere Formulierung für dieselbe Idee.
Ja, es gefällt mir so besser, es ist eben von einer anderen Seite aus betrachtet. Aber Vorsicht, wir kommen in die Nähe der nächsten Haarspaltung. ;)
Wenn ich die Vendor/Device-ID auslese und vergleiche, passiert in der Regel nichts böses. Wenn ich dagegen in irgendeinen Port einen Wert schreibe, um mal zu schauen, was zurückkommt, dann kann alles mögliche passieren...
Natürlich kann beim I/O-Port-Proben alles mögliche unvorhersehbare passieren, aber das Konzept ist das selbe (ob Du nun auf I/O-Ports oder auf Strukturen probest ist konzeptionell kein Unterschied) und ich persönlich finde dieses Konzept eben irgendwie doof. Aber auch hier sind wir wieder gefährlich nahe dem Haarespalten.
sondern beispielsweise die Beschreibung des Core-Moduls (was ja auf der Hauptseite verlinkt ist). Natürlich kann man da noch mehr machen, aber ich bin mir nicht sicher, ob ich weiß, was genau.
Hab ich gelesen und mein ehrliches Fazit ist "bescheiden". Klar ist es extrem schwierig etwas zu beschreiben was einem als völlig logisch im Kopf herumschwirrt, ich versuche mir mal in nächster Zeit eine Art Fragenliste auszudenken.
Plus ein paar von CDI mehr oder weniger genau festgelegte Sachen aus libc-Headern wie Stringfunktionen oder malloc/free.
Damit kann ich sehr gut leben, schließlich sind meine Treiber eh ganz normale User-Mode-Programme.
Welche Ansprüche werden z.B. an die IPC-Mechanismen gestellt? Du weißt das ich da schon etwas von den üblichen/ausgetrampelten Pfaden abweichen will.
IPC ist ein Implementierungsdetail von CDI auf deinem OS. Die Schnittstellen müssen für einen Monolithen, der alles im Kernel laufen lässt, genauso gut funktionieren wie für deinen Mikrokernel mit spezieller IPC.
Das ist mir klar, eben deswegen wüsste ich gerne welche Zusicherungen CDI mit diesen Schnittstellen macht. Wenn ich z.B. einen Pointer in einen Treiber rein gebe welche Ansprüche werden an diesen Pointer gestellt? Mal abgesehen davon das er nicht NULL sein sollte.
Deine Applikationen gehen doch wohl nicht direkt zum FS-Treiber, sondern zu irgendeinem Cache?
Natürlich soll es einen zentralen VFS geben der auch Cache enthält, aber es ist auch möglich das die Dateien das erste mal benötigt werden und noch nicht im Cache vorrätig sind.
Im Moment ist alles synchron und Nebenläufigkeit ist verboten.
Hm, doof! Das wäre für mich ganz klar ein KO-Kriterium, aber ihr wollt das ja noch ändern und bis ich so weit bin CDI tatsächlich einbinden zu wollen vergeht sicher noch einiges an Zeit.
Bevor man das ändert, muss man sich aber erstmal klar werden, welches Konzept man verfolgen will (grundsätzliche Optionen sind callbackbasiert oder threadbasiert).
Aus dem Bauch heraus würde ich mich für threadbasiert entscheiden (aber das hast Du sicher schon erraten), vielleicht könntest Du die 2 Möglichkeiten mal etwas detaillierter erläutern damit ich auch richtige Argumente finden kann (ein neuer Thread im tyndur-Board wäre dafür sicher gut).
Hm, ich weiß gar nicht, inwiefern das bei deinem Konzept überhaupt nötig ist.
Aus meiner heutigen Sicht gar nicht, mir wird wohl void*/size immer reichen. Ob der Speicher per Sharing/IPC in einen Prozess gekommen ist oder von malloc stammt (oder gar auf dem Stack liegt) macht erst mal keinen echten Unterschied (sollte doch bei Flat-Memory genauso sein). Auch das festpinnen im physischen Speicher und generieren einer scatter/gather-Liste (die auch mehrere Einträge haben kann da meine Segmente ja durchaus fragmentiert im physischen Speicher liegen können) soll bei mir erst der unterste Treiber machen (also für Dateizugriffe erst der AHCI-Treiber) und der gibt den Speicher ja nicht mehr weiter. Ich sehe keine Notwendigkeit Speicher festzupinnen bevor nicht auch wirklich seine physische Adresse benötigt wird und die ist eben nur am untersten Ende in dem Treiber-Stapel nötig und daher müssen keine derartigen Infos durchgereicht werden.
Grüße
Erik
-
sondern beispielsweise die Beschreibung des Core-Moduls (was ja auf der Hauptseite verlinkt ist). Natürlich kann man da noch mehr machen, aber ich bin mir nicht sicher, ob ich weiß, was genau.
Hab ich gelesen und mein ehrliches Fazit ist "bescheiden". Klar ist es extrem schwierig etwas zu beschreiben was einem als völlig logisch im Kopf herumschwirrt, ich versuche mir mal in nächster Zeit eine Art Fragenliste auszudenken.
Mach das bitte. Davon, dass du es ein ums andere mal bescheiden und unbrauchbar nennst, wird es jedenfalls nicht besser.
Das ist mir klar, eben deswegen wüsste ich gerne welche Zusicherungen CDI mit diesen Schnittstellen macht. Wenn ich z.B. einen Pointer in einen Treiber rein gebe welche Ansprüche werden an diesen Pointer gestellt? Mal abgesehen davon das er nicht NULL sein sollte.
Eigentlich keine. Der Treiber geht dann aber anschließend ran und verlangt für die cdi_mem_area die passenden Flags, die er gern hätte, z.B. physisch zusammenhängend und auf 16 Bytes alignt. Wenn das dann noch nicht passt, muss die CDI-Implementierung umkopieren oder was auch immer, um die richtigen Bedingungen herzustellen. In der Regel dürfte das aber auf ein nop rauslaufen, wenn die Hardware keine besonderen Wünsche hat.
Im Moment ist alles synchron und Nebenläufigkeit ist verboten.
Hm, doof! Das wäre für mich ganz klar ein KO-Kriterium, aber ihr wollt das ja noch ändern und bis ich so weit bin CDI tatsächlich einbinden zu wollen vergeht sicher noch einiges an Zeit.
Und falls es bis dahin nicht erledigt ist, kannst du dich selbst drum kümmern, das Interface zurechtzubiegen. Das wirklich entscheidende ist, dass es bisher noch nie ein Problem war, CDI einfach zu ändern, wenn irgendwo etwas nicht gut genug war. Ich habe auch nicht vor, das in absehbarer Zeit einzuschränken.
Bevor man das ändert, muss man sich aber erstmal klar werden, welches Konzept man verfolgen will (grundsätzliche Optionen sind callbackbasiert oder threadbasiert).
Aus dem Bauch heraus würde ich mich für threadbasiert entscheiden (aber das hast Du sicher schon erraten), vielleicht könntest Du die 2 Möglichkeiten mal etwas detaillierter erläutern damit ich auch richtige Argumente finden kann (ein neuer Thread im tyndur-Board wäre dafür sicher gut).
Die threadbasierte Variante wäre eben, dass wenn du gleichzeitig zwei Requests hast, dass jeder in seinem Thread abläuft und die Synchonisierung z.B. über Mutexe läuft. Vorteil ist, dass der Code für den einzelnen Request immer noch schön sequenziell ist wie bisher, Nachteil, dass man das Locking korrekt hinkriegen muss.
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...
Aus meiner heutigen Sicht gar nicht, mir wird wohl void*/size immer reichen.
Dann wird deine Implementierung für cdi_mem_alloc eben eine ziemlich einfache. :)
Aus CDI-Sicht sind das aber alles Implementierungsdetails, die den Treiber nicht so richtig zu interessieren brauchen. Er hat halt seine Abstraktion für Speicherbereiche und gut.
-
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...
Ich hab da in letzter Zeit auch ein bisschen über die Schnittstelle zwischen Dateisystem- und Massenspeicher-Treiber nachgedacht für mein OS. Für sowas wie beispielsweise ext2 dürfte doch die Callback-Basierte Variante relativ schön rauskommen. Im ersten Schritt setze ich Requests an das Backend für die direkten Blocks und die ersten Blocktabellen ab, im zweiten Schritt dann die einfach indirekten Blocks und weitere Tabellen, und so weiter. Das dürfte doch Performance-Mässig relativ gut rauskommen wenn man die Requests fürs Backend irgendwie schön asynchron umsetzen kann.
-
Sagen wir so: Ich kenne einen gewissen callbackbasierten Imageformattreiber näher als es vielleicht gut wäre, und bisher habe ich mich beharrlich geweigert, ihn komplett asynchron zu machen, weil ich mir mit den Abhängigkeiten zwischen Requests jetzt schon gelegentlich Knoten ins Hirn denke. Wobei ich natürlich auch sagen muss, dass ich noch keinen ernsthaften Versuch unternommen habe - vielleicht würde es doch besser klappen als erwartet...
Auf jeden Fall müsste cdi/fs dafür komplett überarbeitet werden.
-
Hallo,
Mach das bitte.
Okay.
Was mir am meisten Fehlt ist eine Art Anleitung wie man CDI benutzen muss, quasi ein roter Faden der einem beim Lesen begleitet. Ich weiß dass das doof klingt aber besser beschreiben kann ich es nicht. Wenn man sich die Doxygen-Seite anschaut wird man vor allem mit Fakten erschlagen aber man sieht nur wenig Zusammenhang. Die 2 Bildschirmseiten Haupt-Text sind auf jeden Fall nicht genug um erst mal einen Überblick zu bekommen und eine grobe Vorstellung was man mit CDI eigentlich machen soll.
Es gibt zwar eine Liste was ein Treiber alles benutzen darf aber nirgends ist beschrieben was ein IRQ-Handler alles darf. Meine IRQ-Handler z.B. dürfen alles, sogar selber IPC benutzen (z.B. für fread). Auch sehe ich nicht wann ein IRQ beim IRQ-Controller quittiert wird.
Ich hoffe das ich am WE noch etwas Zeit finde um mir mehr Fragen auszudenken.
Davon, dass du es ein ums andere mal bescheiden und unbrauchbar nennst, wird es jedenfalls nicht besser.
Ja, Du hast recht, Sorry.
Wenn ich z.B. einen Pointer in einen Treiber rein gebe welche Ansprüche werden an diesen Pointer gestellt? Mal abgesehen davon das er nicht NULL sein sollte.
Eigentlich keine.
Das klingt sehr gut.
Wird eigentlich garantiert das ein Treiber bei Schreibkommandos nie selber schreibend auf die Nutzdaten zugreift und umgekehrt? (Ich hoffe die Frage ist verständlich) Ich kann meine Segmente nicht nur als RW sondern auch als RO oder als WO markieren.
Der Treiber geht dann aber anschließend ran und verlangt für die cdi_mem_area die passenden Flags, die er gern hätte, z.B. physisch zusammenhängend und auf 16 Bytes alignt. Wenn das dann noch nicht passt, muss die CDI-Implementierung umkopieren oder was auch immer, um die richtigen Bedingungen herzustellen. In der Regel dürfte das aber auf ein nop rauslaufen, wenn die Hardware keine besonderen Wünsche hat.
Okay, das klingt ebenfalls sehr gut. Bei mir wird es solche Restriktionen jedenfalls nicht geben so das mich die Flags in cdi_mem_area wohl nicht interessieren werden.
Und falls es bis dahin nicht erledigt ist, kannst du dich selbst drum kümmern, das Interface zurechtzubiegen.
Gerne, aber das ist noch recht ferne Zukunft.
Die threadbasierte Variante wäre eben, dass wenn du gleichzeitig zwei Requests hast, dass jeder in seinem Thread abläuft und die Synchonisierung z.B. über Mutexe läuft. Vorteil ist, dass der Code für den einzelnen Request immer noch schön sequenziell ist wie bisher, Nachteil, dass man das Locking korrekt hinkriegen muss.
Das mit dem Locking ist meiner persönlichem Meinung nach nicht all zu schwer, auf jeden Fall finde ich den Vorteil des sequenziellen Codes beim Verstehen desselben als überaus Wertvoll.
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...
Ich denke nicht das die Performance der Callback-Version besser ist, zum einem weil die Logik für die State-Maschine auch CPU-Zeit frisst (das dürfte sich mit den Kontext-Wechseln der Thread-Version ungefähr die Waage halten) und zum anderen skaliert diese Variante nicht mit mehreren CPUs (was IMHO schon wichtig ist und auch immer wichtiger wird), das könnte man zwar ausgleichen in dem man genau so viele Threads für die State-Maschine erstellt wie es CPUs gibt aber dann muss man auch wieder synchronisieren und hat im Endeffekt nur die Nachteile beider Varianten kombiniert. Ein weiterer Nachteil der Callback-Version ist das man den Source-Code nur dann versteht wenn er mit guten graphischen State-Diagrammen und einem fetten Haufen an Erklärungen in Textform dokumentiert ist. Sowas macht richtig viel Arbeit aber wenn man das nicht macht versteht den Code nicht nur kein anderer sondern man läuft Gefahr das man auch selber nicht mehr durchblickt.
Ich hab da in letzter Zeit auch ein bisschen über die Schnittstelle zwischen Dateisystem- und Massenspeicher-Treiber nachgedacht für mein OS. Für sowas wie beispielsweise ext2 dürfte doch die Callback-Basierte Variante relativ schön rauskommen. Im ersten Schritt setze ich Requests an das Backend für die direkten Blocks und die ersten Blocktabellen ab, im zweiten Schritt dann die einfach indirekten Blocks und weitere Tabellen, und so weiter. Das dürfte doch Performance-Mässig relativ gut rauskommen wenn man die Requests fürs Backend irgendwie schön asynchron umsetzen kann.
Das klingt schon verlockend, gerade ein einfacher Block-Device-Treiber sollte nur eine recht kleine State-Maschine benötigen die man tatsächlich noch beherrschen kann (und die Möglichkeiten von SATA/AHCI sind dem parallelen abarbeiten von HDD-Zugriffen auch förderlich). Die Frage ist nur ob der theoretische Performancevorteil wirklich so groß ist das er sowas rechtfertigt oder kommt man mit der Thread-Variante auch schon ganz gut ans Ziel (zum vorauseilenden Einlesen der nächsten Blocklisten könnte man ja einen extra Thread lostreten).
Grüße
Erik
-
Wird eigentlich garantiert das ein Treiber bei Schreibkommandos nie selber schreibend auf die Nutzdaten zugreift und umgekehrt? (Ich hoffe die Frage ist verständlich) Ich kann meine Segmente nicht nur als RW sondern auch als RO oder als WO markieren.
Hm, darüber habe ich mir ehrlichgesagt noch keine Gedanken gemacht. Vorgesehen ist es momentan nicht.
Ich denke nicht das die Performance der Callback-Version besser ist, zum einem weil die Logik für die State-Maschine auch CPU-Zeit frisst (das dürfte sich mit den Kontext-Wechseln der Thread-Version ungefähr die Waage halten)
Hm, ich glaube nicht, dass da eine großartige zusätzliche Logik dabei ist. Wenn irgendwas erledigt ist, wird halt ein Callback-Funktionspointer aufgerufen, mehr nicht. Wobei "irgendwas erledigt" bei tyndur vermutlich heißen würde, dass ein RPC reinkommt (entweder von einem anderen Service oder vom Kernel für einen IRQ).
Die Callbackmethode kommt mir zumindest mit dieser Implementierung natürlicher vor (und sie verlangt allgemein weniger vom implementierenden OS - nicht jeder hat Threads).
und zum anderen skaliert diese Variante nicht mit mehreren CPUs (was IMHO schon wichtig ist und auch immer wichtiger wird), das könnte man zwar ausgleichen in dem man genau so viele Threads für die State-Maschine erstellt wie es CPUs gibt aber dann muss man auch wieder synchronisieren und hat im Endeffekt nur die Nachteile beider Varianten kombiniert.
Hm, ja. Wobei ein Gerätetreiber wohl eher nicht CPU-bound sein sollte.
Ein weiterer Nachteil der Callback-Version ist das man den Source-Code nur dann versteht wenn er mit guten graphischen State-Diagrammen und einem fetten Haufen an Erklärungen in Textform dokumentiert ist. Sowas macht richtig viel Arbeit aber wenn man das nicht macht versteht den Code nicht nur kein anderer sondern man läuft Gefahr das man auch selber nicht mehr durchblickt.
Kommt drauf an, wie viele Zustände der Automat denn hat. ;) Aber es ist schon richtig, tendenziell wird es unübersichtlich.
Vielleicht sollten wir einfach mal ein Beispiel in beiden Modellen durchspielen. Angenommen wir haben ein Gerät, das zwei Requests hat, eine gewisse Menge Daten rauszuschreiben. Wir können immer nur einen bestimmten Teil davon auf einmal rausschreiben und kriegen einen IRQ, wenn das Gerät wieder bereit ist, mehr Daten anzunehmen. Das dürfte nicht so furchtbar exotisch sein, oder?
Bei der callbackbasierten Variante würde ich die Synchronisation wahrscheinlich so machen, dass ich eine Queue der Requests bastle und bei jedem IRQ daraus die vordersten Einträge rauslese und verarbeite. Wenn die Hardware Vollzug meldet, muss ich in der Lage sein, das wieder dem passenden Request zuzuordnen, um den Callback aufzurufen.
Wie würdest du bei der threadbasierten Variante vorgehen? Irgendwie muss ich jetzt die IRQs auf den passenden Thread mappen. Also im Prinzip die gleiche Vorgehensweise, nur dass ich mir nicht den Callback merke, sondern welchen Thread ich aufwecken muss?
-
Hallo,
Ich denke nicht das die Performance der Callback-Version besser ist, zum einem weil die Logik für die State-Maschine auch CPU-Zeit frisst (das dürfte sich mit den Kontext-Wechseln der Thread-Version ungefähr die Waage halten)
Hm, ich glaube nicht, dass da eine großartige zusätzliche Logik dabei ist.
Ich behaupte das hängt sehr vom Treiber ab, bei einem Block-Device-Treiber dürfte das wirklich sehr bescheiden bleiben wohingegen ein Dateisystemtreiber da schon deutlich komplexer wird. Ich bin eben der Meinung das der Performanceunterschied nicht so riesig werden wird, bei einer richtig komplexen Statemaschine ist eventuell ein Kontextwechsel in einen anderen Thread billiger und bei einer sehr simplen Statemaschine wohl eher der State-Wechsel, so das ich denke das dies kein wesentliches Kriterium darstellt.
Wobei "irgendwas erledigt" bei tyndur vermutlich heißen würde, dass ein RPC reinkommt (entweder von einem anderen Service oder vom Kernel für einen IRQ).
Micro-Kernel eben, bei einem Monolithen ist das eventuell etwas schwieriger weil man den Call-Back wohl nicht direkt im IRQ-Handler machen will, da bräuchte man dann irgendeinen geeigneten Mechanismus für nichtblockierende verzögerte Call-Backs.
und sie verlangt allgemein weniger vom implementierenden OS - nicht jeder hat Threads
Hm, das sollte etwas genauer erörtert werden. Threads sind sicher keine Anfängerübung aber richtiges Call-Back bestimmt auch nicht. Das Problem ist eben wie so ein Call-Back angenommen wird, die tyndur-Methode hat eben auch so ihre Tücken weil da schnell mal ein Treiber komplett blockieren könnte nur weil er momentan seinen Call-Back nicht los bekommt (das wäre IMHO ein KO-Kriterium).
Wobei ein Gerätetreiber wohl eher nicht CPU-bound sein sollte.
Warum nicht? Was denkst Du warum AHCI/SATA das tolle MSI-(X) unterstützt? Auch viele aktuelle Ethernet-Controller können gerade deswegen jedem Job einen bestimmten von mehreren IRQs zuordnen.
Vielleicht sollten wir einfach mal ein Beispiel in beiden Modellen durchspielen. Angenommen wir haben ein Gerät, das zwei Requests hat, eine gewisse Menge Daten rauszuschreiben. Wir können immer nur einen bestimmten Teil davon auf einmal rausschreiben und kriegen einen IRQ, wenn das Gerät wieder bereit ist, mehr Daten anzunehmen. Das dürfte nicht so furchtbar exotisch sein, oder?
Exotisch ist das sicher nicht aber IMHO eben auch etwas zu simpel um da wirklich spezifische Vorteile oder Nachteile herausarbeiten zu können.
.... Also im Prinzip die gleiche Vorgehensweise, nur dass ich mir nicht den Callback merke, sondern welchen Thread ich aufwecken muss?
Ganz genau. Eben deswegen finde ich das Beispiel etwas zu simpel.
Als komplexeres Beispiel würde ich da schon eher einen Dateisystemtreiber bevorzugen, nur leider hab ich davon kaum Ahnung so das ich mir da auch kein realistisches Szenario ausdenken kann. TCP wäre sicher auch ein sehr interessanter Kandidat. Andere Vorschläge?
Grüße
Erik