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
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken
Thema: Allgemeine Fragen (Gelesen 26286 mal)