1
Lowlevel-Coding / Re: CDI und Monolith
« am: 24. August 2013, 14:21 »
Jup, das steht auch im Kommentar: http://git.tyndur.org/?p=cdi.git;a=blob;f=include/cdi/storage.h#l174
10. December 2024, 07:33
Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.
Habe ich das richtig verstanden, dass die Funktion cdi_fs_data_read() einen oder mehrere Sektoren vom entsprechenden Gerät liest, auf das dieses Dateisystem ist? Also z.B. von einem ATA-Gerät?Ja. Um welches Gerät/welche Datei es geht (die also gemountet ist), speichert das OS (bzw. die CDI-Bibliothek) normalerweise irgendwie in cdi_fs_filesystem.osdep.
Ich habe in der Dokumentation von einer Funktion namens "cdi_driver_run()" oder so ähnlich gelesen. Ich kann diese aber nirgendwo im cdi-Header (cdi.h) finden.Öffa, ich glaube, die Funktion ist veraltet. Heute geht man halt alle Treiber durch, die man hat, und ruft da jeweils die init-Funktionen auf (ich persönlich scheine das nicht zu machen, aber das schiebe ich jetzt mal auf Unvermögen meinerseits) und registriert die Treiber beim System (per cdi_foo_driver_register). Wenn dann ein Gerät reinkommt, ruft man bei allen (vom Typ und Bussystem her in Frage kommenden) Treibern die init_device-Funktion auf, die testet, ob das Gerät kompatibel ist. So viele Treiber gibts bei CDI ja (noch) nicht, da kann man das schon so machen.
Ich war mir sicher das GCC in so einem Fall warnt. Aber das tut er scheinbar nur wenn die shift-Weite >= 32 ist, egal ob u8 oder char.Das kommt übrigens, weil der zu shiftende Operand erstmal implizit zu int konvertiert wird (wenn er reinpasst; C11, 6.5.7 Abs. 3 bzw. 6.3.1.1 Abs. 2). Deshalb ist die Anzahl der zu shiftenden Bit nicht größer/gleich der Operandenbreite (die eben sizeof(int) * 8 = 32 ist) und es gibt keinen Grund zu warnen.
Darunter wird das tatsächlich still und heimlich zu einer 0 optimiert.
Warum muss man denn SSE oder AVX initialisieren? Mein Kernel initialisiert nur die FPU aber SSE nicht und die Programme können SSE ohne Probleme verwenden.Zumindest ein Programm zu einem Zeitpunkt. Wenn man FPU/SSE erlaubt, muss man beim Taskwechsel ggf. darauf achten, den Zustand der FP- bzw. XMM-Register zu sichern (fxsave/fxrestor). Wie man die obere Hälfte der YMM-Register sichert, weiß ich nicht.
AVX ist allerdings nicht gut dokumentiert.Eigentlich ist AVX schon ziemlich gut dokumentiert – soweit ich weiß, erweitert es einfach die 128-Bit-XMM-Register zu 256-Bit-YMM-Registern (auf denen man dann weiterhin die SSE-Befehle ausführen kann) und führt (für zumindest einige SSE-Befehle) das drei-Operanden-Format ein, oder gibt es da sonst noch was neues?
In der Implementierung dürfte es ja recht einfach seinDer war gut. Ich wünsche viel Spaß.
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.
Mal vom Aufwand abgesehen, da es sich beim Linux-Kernel ja um GPL-Code handelt sollte es doch für ein Micro-Kernel-OS möglich (und auch legal) sein alles was man für einen bestimmten Treiber benötigt aus dem Linux-Kernel komplett hinaus zu filetieren und als eigenständigen User-Mode-Prozess laufen zu lassen oder? Man müsste doch eigentlich nur die Teile des Linux-Codes anpassen/ersetzen die das Treiber-Management (z.B. IRQ-Handler an/ab-melden oder HW-Speicher ein/aus-blenden) betreffen oder?Ich hab mich mal in eine Microkernelvorlesung verirrt, in der genau das getan wurde. Da gibt es irgendeine Art Bibliothek für L4 (wimre), die den Linuxkernel darstellt, und wenn man Treiber gegen die linkt, kann man die halt im Userspace ausführen und Linuxtreiber unter L4 benutzen. Das wurde auch live gemacht, also da saßen alle im Rechnerpool und vorne standen die URLs, wo man die Bibliothek und ein L4-Image bekommt und dann hieß es „So, jetzt sucht euch einen Hallo-Welt-Treiber im Netz oder so und probiert das mal in qemu aus“.
ich frage mich ob ein man ein Treiber als einen eigenen Prozess betrachten sollDas sind Microkernel (jeder Treiber ist ein Prozess).
oder als eine Art LibraryDas sind Exokernel (jeder Prozess erhält vollen Hardwarezugriff und die Bibliothek enthält Funktionen, um den Zugriff zu abstrahieren – diese Funktionen sind also die Treiber).
Also mit Letzterem meine ich so etwas ähnliches wie ein Kernel.Das sind Monolithen (die Treiber sind im Kernel und jeder Prozess ruft über Syscalls die Treiber auf, um den Hardwarezugriff durchzuführen).