Hallo,
der große Vorteil eines Monolithen ist, dass du interne Funktionen ohne Overhead aufrufen kannst, es also bestimmte Funktionalität nur einmal im gesamten Kernel geben muss. Da sind Bugfixes maximal effektiv.
Also wenn diese Funktionen in einer DLL liegen dann sind sie aus mehreren User-Mode-Treibern mit genau so wenig Overhead aufzurufen und belegen auch nur einmal RAM/Cache und lassen sich genau so zentral warten. Sorry, aber das zählt nich. Der große Nachteil dieses Funktions-Sharings ist das wenn ein Subsystem-Entwickler sich so eine Funktion ausgedacht hat und diese dann plötzlich von den Treibern anderer Subsysteme auch benutzt wird das dann plötzlich (möglicherweise sogar ohne es zu wissen) der erste Entwickler seine Funktion nicht mehr einfach so modifizieren kann da das plötzlich unvorhergesehene Rückwirkungen auf ganze andere Dinge im Kernel hat. Diese Art von Spagetti-Code ist grundsätzlich nicht schön und ich persönlich würde gerne 0,2% System-Performance opfern wenn dafür ein stabileres System entsteht.
Viele API-Änderungen sind aber nur relativ klein bzw. lassen sich in den Treibern ohne größeren Aufwand automatisiert umsetzen
Ich hätte jetzt eher daran gedacht das ich aus einer bestimmten Kernel-Version bestimmte Treiber heraus filetiere, indem man ein Tool benutzt dem man sagt welche Dateien man unverändert bekommen will (den Treiber) und dieses Toll dann die Abhängigkeiten im restlichen Kernel iterativ durchgeht und genau das was benötigt wird mit ausschneidet. Letzteres abzüglich der Funktionen die ich selber anbieten muss und auch nur bei diesen Funktionen muss ich zuerst (händisch) prüfen ob sich dort die API und/oder die Funktionalität geändert hat.
Schlimmer ist, dass die ABI nicht stabil ist, was Binärtreiber verunmöglicht. 
Einige HW-Hersteller haben mehr oder minder erfolgreich vorgeführt das auch dieses Problem lösbar ist.
Theoretisch kannst du jeden Treiber mit einem halben Linux verheiraten und im Userspace laufen lassen, ob das aber mehr Spaß macht als den Treiber zu reversen und neu zu entwickeln, kann ich nicht einschätzen.
Es geht mir nicht um den Spaß sondern darum ein Ziel mit möglichst geringem Aufwand zu erreichen und ich will auch nicht den halben Linux-Kernel sondern nur genau das was der Treiber benötigt und nicht eh von mir kommen muss (weil gewisse Dinge eben zu meinem OS passen müssen, alles andere würde auf nahezu vollwertiges User-Mode-Linux hinauslaufen).
Vermutlich kommst du da mit den BSD-Treibern eher weiter, die haben da - soweit ich das einschätzen kann - kleinere Schnittstellen. Andererseits ist z.B. der nouveau-Treiber von den Entwicklern als Kernel- und Userspace-Treiber ausgelegt worden, damit die bei der Entwicklung "mal eben schnell" eine Änderung testen können.
Okay, es gibt also mehr Quellen als nur den Linux-Kernel, wenn mein oben beschriebenes Tool flexibel genug ist sollte auch das kein Problem sein.
Ich denke, wenn man sich auf Treiber einer Klasse (z.B. Ethernet) beschränkt, kann man Linux-Treiber portieren. Wenn man aber alle/viele verschiedene Treiber übernehmen will, läuft das auf eine Reimplementation von Linux im eigenen Kernel raus.
Naja, also wenn dann geht es IMHO schon darum die typischen PCs die Media-Markt/Saturn/ALDI/... in den letzten X Jahren verkauft haben zu unterstützen damit mein kleines Hobby-OS auf möglichst vielen potentiellen PCs läuft. Wenn wir uns mal ansehen für welche HW es CDI-Treiber gibt dann muss man ganz klar sagen das deren Zielgruppe die virtuellen PCs von VMware und Co sind. Klar auch das ist ein Markt, wenn man damit (und den anderen Nachteilen von CDI) zufrieden ist dann ist CDI eine interessante Wahl aber wenn man mehr will dann ist es eventuell ratsam doch mal die Alternativen zu prüfen.
Windows-Treiber haben den Vorteil der Verfügbarkeit, sind aber meist hinreichend schlecht/instabil programmiert.
Um ersteres geht es mir doch und ob ich als Hobby-OS-Dever im zweiten Punkt mit eigenen Treibern so viel besser abschneiden würde steht auf einem anderen Blatt (deswegen bin ich ja so an den Linux-Treibern interessiert, die sind ebenfalls gut verfügbar und meistens von mindestens ebenwürdiger Qualität).
Außerdem ist es trotzdem eine ziemlich heftige API, die man unterstützen muss (Binärformate, ...).
Das ist wohl war. Die Windows-Treiber-API gibt es in verschiedenen Geschmacksrichtungen und jede Treiber-Sorte benötigt eine eigene API und dann hat man oft sogar noch die Wahl ob der Treiber im User-Mode oder im Kernel-Mode laufen soll. Aber gemessen an dem Aufwand den man investieren müsste um alle gewünschten Treiber selber zu entwickeln ist das vielleicht gar nicht mal so viel wie es scheint. Nebst dessen das man sich vielleicht bei ReactOS bedienen kann.
Portabel ist es dann auch nicht, aber bei einem Hobby-OS tut das nicht unbedingt weh.
Zumindest x86 in 32Bit und 64Bit und demnächst auch ARM in 32Bit und 64Bit sind doch schon mal was. Was will den der klassische Hobby-OS-Dever (der keine eigene Plattform bauen möchte, so wie wir beide) mehr?
Grüße
Erik
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken
Thema: Windowstreiber-Schnittstelle (Gelesen 18111 mal)