Thema: Windowstreiber-Schnittstelle

[erik.vikinger]

Hallo,

(z.B. dass vaddr->paddr niemals einen page table walk durchführt und daher schnell ist)

Also wenn damit gemeint ist das eine virtuelle Adresse in die zugehörige physische Adresse umgewandelt wird glaube ich nicht mal das gar kein Page-Teble-Walk durchgeführt wird, in irgendeiner Art von Datenstruktur (was natürlich nicht zwangsläufig eine Page-Table für die CPU sein muss) muss diese Information schließlich verwaltet werden. Spätestens wenn eine I/O-MMU ins Spiel kommt ist diese Funktion nicht mehr trivial. Auch müsste überlegt werden ob diese Performance noch erreicht wird wenn die virtuelle Adresse zu einem der User-Spaces gehört.

Zu sagen, CDI habe deshalb diese Zielgruppe, ist aber falsch. CDI hat keine Zielgruppe.

Sorry, da habe ich mich offensichtlich falsch ausgedrückt. Mir ist schon klar dass das keine absichtliche Entscheidung der Entwickler war primär die HW der Virtualisierer zu unterstützen sondern das es einfach ein logischer Schritt war da die Entwickler wohl oft (aber sicher nicht ausschließlich) mit einer virtuellen Maschine arbeiten. Es ging mir eher darum dass das momentan real vorhandene Treiber-Arsenal von CDI einen gefühlten Schwerpunkt auf diese Art der Geräte hat.

Aus meiner Sicht ist z.B. der Aspekt das die Treiber wohl selber bestimmen müssen ob sie sich für ein bestimmtes Gerät zuständig fühlen ein konzeptioneller Nachteil, IMHO wäre es besser wenn z.B. ein zentraler PCI-Service alle Geräte nimmt und in einer Datenbank (o.ä.) nachschaut welchen Treiber er für jedes Gerät laden soll. Ein anderer Nachteil ist z.B. das pro Gerät nur ein IRQ möglich ist.


Grüße
Erik

[Svenska]

Hallo,

Um Linux-Treiber automatisiert übernehmen zu können, musst du in deiner Semantik so nah am Original sein, dass du dir die Kopie auch gleich sparen kannst.

Also davon bin ich jetzt noch nicht überzeugt. Letztendlich kocht Linux auch nur mit Wasser, also warum sollte ich diese Features/Eigenheiten nicht auch hinbekommen?

Ich dachte, deine Architektur möchte die Speicherverwaltung etwas anders erledigen? Ernsthaft: Sicher kannst du die ganzen schmutzigen Details so implementieren, wie Linux das tut, aber dann kannst du theoretisch auch Linux benutzen.

Die kritische Frage ist doch eher ob diese subtilen Dinge auch sauber dokumentiert sind.

Natürlich nicht, sonst wären sie ja nicht subtil... es gab z.B. auch eine Menge Fallout in Bezug auf Big-/Little-Endian (betraf v.a. die PPC-Macs mit PCI-Steckplätzen), wo die Treiber das nicht sauber berücksichtigt haben.

Aber beim heutigen Verbreitungsgrad von x64 sind die Lücken bereits recht dünn. Welcher HW-Hersteller kann es sich den leisten das seine HW von aktuellem Windows nicht unterstützt wird?

Jeder, wenn es nicht gerade um die neuste Hardware geht. Denk mal so: Du wirst auf deinem aktuellem PC kein Hobby-OS produktiv einsetzen. Wenn es überhaupt reale Hardware bekommt, dann ist das ältere Hardware. Da hast du große x64-Löcher.

und bei ARM wäre ich auch sehr überrascht, wenn sich dort ein halbwegs gebrauchbares Arsenal finden würde

Okay, aber immerhin soll z.B. der Tegra 3 unterstützt werden und für diesen z.B. einen halbwegs brauchbaren Grafik-Treiber zu bekommen ist doch schon mal was.

Einen beschleunigten 2D-Treiber gibt es ab Kernel 3.8, vgl. hier. Bei 3D sieht die Situation genauso aus wie bei allen anderen ARM-Herstellern.

Die libusb kenne ich auch aber das es auf dieser Basis "richtige" Treiber gibt wusste ich noch nicht.

Da gibt es ganz viel Userspace-Kram, also Scanner und sowas. Mit HID, MSC und dem üblichen Zeug sieht das anders aus, weil das recht tief in den Subsystemen verwurzelt ist. Das gibt es schon, aber es bringt nichts, weil die Programme zwar die Hardware ansteuern, aber keine wirklichen Treiber sind.

(z.B. dass vaddr->paddr niemals einen page table walk durchführt und daher schnell ist)

Also wenn damit gemeint ist das eine virtuelle Adresse in die zugehörige physische Adresse umgewandelt wird

War mein Fehler, ich meinte den umgekehrten Fall, paddr->vaddr. Linux hat die Speicherverwaltung so designt, dass da nur eine Konstante drauf addiert wird, was die Berechnung billig macht. Für IOMMUs gilt vermutlich das gleiche.

Es ging mir eher darum dass das momentan real vorhandene Treiber-Arsenal von CDI einen gefühlten Schwerpunkt auf diese Art der Geräte hat.

Siehe oben: Entweder alte Hardware oder VMs.

Gruß,
Svenska

[kevin]

Aus meiner Sicht ist z.B. der Aspekt das die Treiber wohl selber bestimmen müssen ob sie sich für ein bestimmtes Gerät zuständig fühlen ein konzeptioneller Nachteil, IMHO wäre es besser wenn z.B. ein zentraler PCI-Service alle Geräte nimmt und in einer Datenbank (o.ä.) nachschaut welchen Treiber er für jedes Gerät laden soll. Ein anderer Nachteil ist z.B. das pro Gerät nur ein IRQ möglich ist.

Ich weiß, dass deine Herangehensweise eher ist, so lange zu designen, dass man nie etwas umgesetzt bekommt, aber in diesem Fall ist der Grund halt, dass es bisher noch niemand gebraucht hat und es deswegen auch noch nicht existiert. Wozu sollte ich Code schreiben, den ich selber gar nicht brauche?

[erik.vikinger]

Hallo,

Ich dachte, deine Architektur möchte die Speicherverwaltung etwas anders erledigen?

Ja, das ist der Plan. Trotzdem wird auch meine Speicherverwaltung gewisse Features anbieten (müssen) damit ein Treiber z.B. die physische Adresse zu einer virtuellen bekommt oder wenn in Linux gewisse Dinge mit einem kleinen Trick beschleunigt werden können dann kann ich das möglicherweise bei mir auch. Außerdem geht es mir nicht primär um meine eigene Plattform sondern allgemein um das Thema möglichst einfach vorhandene Treiber (egal aus welcher Quelle) in ein Hobby-OS zu bekommen.

Sicher kannst du die ganzen schmutzigen Details so implementieren, wie Linux das tut, aber dann kannst du theoretisch auch Linux benutzen.

Das möchte ich doch gar nicht, ich will doch nur eine User-Space-Library die vom Linux-Kernel gerade genug bietet damit ein Linux-Treiber funktioniert. Die Variante von „Linux on L4“ ist aus meiner Sicht höchstens ein erster Ansatz um überhaupt erst mal das Ziel erreichen zu können (und um erstmal alles das zu programmieren was diese Library für mein OS bieten muss) aber keine vernünftige Dauerlösung.

Die kritische Frage ist doch eher ob diese subtilen Dinge auch sauber dokumentiert sind.

Natürlich nicht, sonst wären sie ja nicht subtil

Wieso nur hab ich das geahnt?! Der Linux-Kernel ist doch das Vorzeigeprojekt der Open-Source-Scene aber eine anständige Doku ist für so ein riesen Ding wohl doch nicht mehr machbar. Schade, da der Linux-Kernel eigentlich die einzigste wirklich umfangreiche Quelle für Open-Source-Treiber ist.

Denk mal so: Du wirst auf deinem aktuellem PC kein Hobby-OS produktiv einsetzen. Wenn es überhaupt reale Hardware bekommt, dann ist das ältere Hardware.

Naja, nicht jeder hat einen älteren Zweitrechner parat nur um mal eben ein Hobby-OS aus dem iNetz auszuprobieren. Aber wenn Du an einen Produktiveinsatz denkst dann hast Du natürlich recht, wobei sich das eventuell mit Hobby-OS minimal beißt.

Einen beschleunigten 2D-Treiber gibt es ab Kernel 3.8, vgl. hier. Bei 3D sieht die Situation genauso aus wie bei allen anderen ARM-Herstellern.

Okay, bin überzeugt.

Die libusb kenne ich auch aber das es auf dieser Basis "richtige" Treiber gibt wusste ich noch nicht.

Da gibt es ganz viel Userspace-Kram, also Scanner und sowas. Mit HID, MSC und dem üblichen Zeug sieht das anders aus, weil das recht tief in den Subsystemen verwurzelt ist. Das gibt es schon, aber es bringt nichts, weil die Programme zwar die Hardware ansteuern, aber keine wirklichen Treiber sind.

Also eine ähnlich bescheidene Situation wie bei FUSE, zwar ein interessantes Konzept mit viel Potential aber es gibt einfach nicht genug reales Zeugs damit sich daraus auch wirklich was ernstzunehmendes ergibt. Schade!

ich meinte den umgekehrten Fall, paddr->vaddr. Linux hat die Speicherverwaltung so designt, dass da nur eine Konstante drauf addiert wird, was die Berechnung billig macht. Für IOMMUs gilt vermutlich das gleiche.

Also auch hier muss ich ehrlich sagen das es mir schwer fällt das zu glauben. Was ist mit reinen 32Bit-System auf denen der physische 4GB-Adressraum komplett ausgeschöpft ist? Ich kann mir nicht vorstellen das im Kernel-Space (der ja nur 2GB groß ist) auch nur alle MMIO-Ranges der HW-Geräte linear rein passen (den RAM lassen wir da mal außen vor). Und die IOMMU spielt in dieser Richtung keine Rolle, nebst dessen das wenn sie so simpel benutzt wird kann man sich das auch gleich ganz sparen.
Vor allem fällt mir gar kein Anwendungsfall ein wo ein Treiber eine physische Adresse in eine virtuelle Adressen umrechnen lassen müsste, so ein Feature möchte ich in meinem OS gar nicht erst anbieten.
In meiner Vorstellung arbeitet ein Treiber doch primär mit den Datenpuffern die er von den normalen Applikationen bekommt (mehr oder weniger direkt) und für diese bekommt der Treiber die virtuelle Adresse für welcher er dann die physische Adresse (welche optional per IOMMU wieder anders virtualisiert ist) benötigt.

Wozu sollte ich Code schreiben, den ich selber gar nicht brauche?

Ist natürlich eine berechtigte Frage. Trotzdem würde ich es als Vorteil erachten wenn das OS nicht einfach alle existierenden Treiber laden und starten muss und ich glaube auch nicht das eine kleine Tabelle (das Wort Datenbank war doch etwas übertrieben) mit den Class-Codes (für generische Treiber) oder Vendor/Device-IDs (für spezifische Treiber) so viel aufwendiger wäre.

Ich weiß, dass deine Herangehensweise eher ist, so lange zu designen, dass man nie etwas umgesetzt bekommt

das war nich lieb


Grüße
Erik

[kevin]

Trotzdem würde ich es als Vorteil erachten wenn das OS nicht einfach alle existierenden Treiber laden und starten muss und ich glaube auch nicht das eine kleine Tabelle (das Wort Datenbank war doch etwas übertrieben) mit den Class-Codes (für generische Treiber) oder Vendor/Device-IDs (für spezifische Treiber) so viel aufwendiger wäre.

Ja. Hat aber noch niemand gemacht. Der erste, der es umsetzt, wird die entsprechenden Änderungen schon vornehmen.