Autor Thema: Das Konzept der LAPI  (Gelesen 18586 mal)

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #20 am: 07. September 2005, 22:44 »
hallo,

also wenn ihr von dll redet, redet ihr vom pe-file format, da wir dieses nicht verwenden, sollten wir unserem kind einen eigenen namen geben.
Ich spreche fürs erste mal von einer shared library (sl).

also die kernel.dll läuft nicht, wie man dem namen nach fälschlicherweise vermuten würde im kernel-mode(Ring0), sondern im user-mode(Ring3).
Diese mappt nur System Calls für der C-WinAPI (gemeinsam mit ntdll.dll)
Ist also nur eine Schnittstelle zwischen Usermode und Kernelmode
(wenn man sich den quellcode der kernel.dll anguckt findet man viele syscall's/sysenter's)

Desweiteren ist anzumerken, dass die Begriffe Treiber und dll (unter windows) nicht auf der selben Ebene stehen.  Auch Treiber verwenden dll's.

Die "Dienste" unter Windows haben zum Großteil auch nichts mit Hardware zu tun. Diese laufen meines wisssens nach nicht im Ring0.
Die Resourcenverteilung dürfte irgendwo im Kernel erfolgen.

Gegen ein modulariertes Konzept habe ich nichts einzuwenden, die Module sollten dynamisch geladen und entladen werden können.
Außerdem sollten die Module hierarchische und abstrahierend sein.
Treiber sollten möglichst in einen eigenen Prozess.
Ich stell mir das so vor.


                Kernel (Disp, PM, MM)
                          |
   +----+---------- Modulverwaltung (Soft Driver)
   |    |                 |
   |    |         Treiberverwaltung (Hard Driver)
   |    |                 |
   |    |             z.B. HDD/FDD/CD/Monitor/usw. Treiber (als eigene Prozesse, mit Bibliotheken für Entrypoints
   |    |                 |
   |    +------+----------+
   |           |
   |           |
   |    SoftDriver z.b Dateisysteme (FAT/FAT32/usw.)
   |           |
   +-- kernelinterner Teil der API (zugriff aus SoftDriver/Module)
               |
      usermode Teil der API (in der Art wie Kernel32.DLL)
               |
            Programm

So in der Art, stell ich mir das vor, da fehlt natürlich noch ne ganze Menge, ist dadurch auch teilweise inkonsistent.
Oder man verlegt Modul- und Treiberverwaltung mit in den Kernel, da diese eh immer benötigt werden.
Aber alle Module sollten generell austauschbar sein.
Das wiederum heißt nicht, das nicht einige Module bestimmte andere Module brauchen.
Aber wenn die Schnittstellen gleich sind, sollen diese austauschbar sein.

Die Module sind shared libs, Die Treiber sind ausführbare Dateien, in Verbindung mit Libs.

Vielleicht sollten wir auch noch mehr Kernelspace reservieren, als es im Moment der Fall ist (von 1GB auf 2GB erhöhen).
Dann könnten bestimmte Speicherbereiche für Treiber Bibliotheken reserviert werden.

Die IDT wird übrigens im Moment nach den globalen Konstruktoren initialisiert.

MfG
DDR-RAM

T0ast3r

  • Gast
Gespeichert
« Antwort #21 am: 09. September 2005, 19:38 »
Hi!

Also ich bin grad am ausarbeiten einer Spezifikation von DLLs und von dem LOST Drive Model.
Den Beitrag von DDR-RAM werde ich nun noch miteinbeziehen.
Wenn ich diese Standarts fertig habe, poste ich sie und verlinke sie hier.
Dann könnt ihr sie durchlesen und kritisieren.
Denn man kann ja noch viel ändern!

 

Einloggen