Autor Thema: Allgemeine Fragen  (Gelesen 13731 mal)

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #20 am: 06. September 2010, 12:50 »
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ß

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #21 am: 06. September 2010, 12:55 »
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.

Zitat
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.

Zitat
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.

Zitat
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. :)

Zitat
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.

Zitat
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.

Zitat
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #22 am: 06. September 2010, 13:06 »
Zitat
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.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #23 am: 06. September 2010, 13:36 »
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #24 am: 06. September 2010, 14:21 »
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

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #25 am: 06. September 2010, 14:40 »
Dachte ich mir schon, dass wieder gekniffen wird, wenn es drum geht, sich die Händer selber dreckig zu machen. ;)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #26 am: 06. September 2010, 15:10 »
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

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #27 am: 06. September 2010, 17:18 »
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.

Zitat
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.

Zitat
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.

Zitat
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
Reality is that which, when you stop believing in it, doesn't go away.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #28 am: 06. September 2010, 17:43 »
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #29 am: 06. September 2010, 17:59 »
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

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #30 am: 06. September 2010, 21:48 »
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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
Reality is that which, when you stop believing in it, doesn't go away.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #31 am: 06. September 2010, 22:19 »
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? ;)

Zitat
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).

Zitat
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?

Zitat
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.

Zitat
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.

Zitat
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. ;)

Zitat
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #32 am: 06. September 2010, 23:33 »
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

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #33 am: 07. September 2010, 09:59 »
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #34 am: 07. September 2010, 12:39 »
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.

Zitat
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
Reality is that which, when you stop believing in it, doesn't go away.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #35 am: 07. September 2010, 14:43 »
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.

Zitat
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...

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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).

Zitat
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.

Zitat
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #36 am: 08. September 2010, 11:43 »
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.

Zitat
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
Reality is that which, when you stop believing in it, doesn't go away.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #37 am: 08. September 2010, 21:00 »
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.

Zitat
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.

Zitat
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.

Zitat
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...

Zitat
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #38 am: 08. September 2010, 21:35 »
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.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #39 am: 08. September 2010, 22:35 »
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

 

Einloggen