Thema: Treiber bei einem Mikrokernel

[erik.vikinger]

Hallo,

Die Ressourcen können geändert werden und das ist auch vorgesehen

Hat das jemand bezweifelt?
Die Frage ist nur wie sinnvoll das ist.
Es macht auf jeden Fall keinen Sinn wenn das BIOS nur einen Teil der PCI-Geräte konfiguriert und den Rest dem OS überlasst eben weil sich damit die Adressen der vom BIOS konfigurierten Geräte ändern können und damit das BIOS nicht mehr funktionieren würde (also z.B. keinen INT 13h mehr anbieten kann).

Ich möchte sogar behaupten das Linux und Windows Code haben für eine neue Ressourcenzuweisung und das es halt den Fall gibt das die Ressourcen gar nicht oder fehlerhaft zugewiesen wurden.

Bei Windows würde ich das eher bezweifeln (außer für Hot-Plugging vielleicht) aber Linux hat solchen Code bestimmt. Linux kann mit Sicherheit die komplette PCI-Enumeration + Ressourcenzuweisung selber erledigen, es soll ja auch auf nicht PC-Systemen laufen wo es eventuell gar kein BIOS gibt. Ob Linux das auch auf einem normalen PC tut kann ich nicht beurteilen aber da es das BIOS ja nie in Anspruch nimmt dürfte es tatsächlich keine negativen Auswirkungen haben wenn alle PCI-Geräte neue Adressen zugewiesen bekommen (wobei ich nicht beurteilen kann ob da eventuell Suspend-to-RAM bzw. Suspend-to-Disk oder irgendwelche SMM-Dinge ein Problem darstellen).


Grüße
Erik

[Svenska]

Ursprünglich hat bei PnP-OS=Enabled das BIOS nur den zum Booten benötigten Geräten die Ressourcen zugeteilt. Und zwar auch nur auf der PCI-Host-Bridge, alles dahinter war nicht erreichbar. In den Systemen gab es auch nur einen PCI-Bus.

[FlashBurn]

Es macht auf jeden Fall keinen Sinn wenn das BIOS nur einen Teil der PCI-Geräte konfiguriert und den Rest dem OS überlasst eben weil sich damit die Adressen der vom BIOS konfigurierten Geräte ändern können und damit das BIOS nicht mehr funktionieren würde (also z.B. keinen INT 13h mehr anbieten kann).

Dem wiederspreche ich mal. Solange du den Kompatibilitätsmodus des IDE-Kontrollers nicht ausstellst, ist der immer hinter den gleichen Ports erreichbar.
Außerdem hat Svenska doch gesagt, das nur das was zum Booten gebraucht wird initialisiert wird und dass das BIOS nach dem Booten eines OS noch funktioniert, davon gehe ich sowieso nicht aus. Wer weiß was das OS alles geändert hat, aber das ist ja auch sein gutes Recht

Edit::

Habe das falsche "nicht" entfernt.

[Svenska]

Äh, nur das, was zum Booten gebraucht wird, wird auch initialisiert; der Rest wird dem Betriebssystem überlassen. Das ist auch dafür nötig, eine BIOS-kompatible Umgebung herzustellen, sofern BIOS-Funktionen später benötigt werden.

Was willst du im Protected Mode auch mit einem int13h?

[erik.vikinger]

Hallo,

dass das BIOS nach dem Booten eines OS noch funktioniert, davon gehe ich sowieso nicht aus

Okay und was ist mit der Emulation von Legacy-Devices (z.B. eines Floopy-Controllers obwohl ein USB-Floppy dran hängt) oder anderen Dingen für die SMM benötigt wird (z.B. Bildschirmhelligkeit bei Laptops)? Es gibt IMHO tausende Gründe warum das BIOS noch funktionieren sollte auch wenn das OS läuft.

Was willst du im Protected Mode auch mit einem int13h?

Massenspeicher ansprechen für die das OS keine eigenen Treiber hat (alle DOS-basierenden Windowsen können das und hier im Forum wurde das auch schon mal für unsere Hobby-OSe diskutiert).


Wieso streite ich mit Euch eigentlich darüber? In mein OS werde ich auf jeden Fall eine ordentliche PCI-Enumeration und Ressourcen-Vergabe implementieren müssen, ich hab ja auch kein BIOS, wenn Ihr das für Eure x86-OSe ebenfalls tun wollt dann bitte. Ich werde mich zu diesem Thema nicht mehr äußern!


Grüße
Erik

[FlashBurn]

Um nochmal was zu dem Thema BIOS und PCI Ressourcen zu sagen, ich habe gerade mal auf meinem Sockel 940 (Opteron) Board im BIOS nachgeguckt und da steht als Erklärung für die genannte Option (Plug&Play OS available) das nur die Ressourcen initialisiert werden, die zum Booten nötig sind.
Damit kann man mit 100%er Sicherheit davon ausgehen, das auch Windows sowas beherrscht!