Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
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
25. April 2024, 03:17
Beiträge anzeigen
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.
2
Lowlevel-Coding / Re: CDI und Monolith
« am: 22. August 2013, 17:11 »
Jeder Treiber, der Geräte verwaltet, muss die eigentlich auch setzen.
Dateisystemtreiber verwalten wiederum keine Geräte, die machen das über fs_init.
Und dann gibts noch so Spezialisten wie ata, die sich alle Geräte in der Treiber-init selbst raussuchen.
Dateisystemtreiber verwalten wiederum keine Geräte, die machen das über fs_init.
Und dann gibts noch so Spezialisten wie ata, die sich alle Geräte in der Treiber-init selbst raussuchen.
3
Lowlevel-Coding / Re: CDI und Monolith
« am: 21. August 2013, 19:03 »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.
4
Lowlevel-Coding / Re: IRQ 11 auf Hardware
« am: 23. July 2013, 19:11 »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.
Nur, um es gesagt zu haben. :3
6
Lowlevel-Coding / Re: SSE benutzen
« am: 17. July 2013, 16:39 »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.
7
Lowlevel-Coding / Re: SSE benutzen
« am: 17. July 2013, 02:52 »
Eine Liste von SSE-Befehlen (bis SSSE3) hätte ich unter http://xanclic.bplaced.net/sse.html. Eine Möglichkeit zum Potenzieren kenne ich nicht.
EDIT: Hm, ja, WP sagt, es gibt auch ein paar neue Befehle, die im Allgemeinen der Behandlung der neuen oberen Hälfte der YMM-Register geschuldet sind. Die stehen aber auch alle in meinem Intelmanual.
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?
EDIT: Hm, ja, WP sagt, es gibt auch ein paar neue Befehle, die im Allgemeinen der Behandlung der neuen oberen Hälfte der YMM-Register geschuldet sind. Die stehen aber auch alle in meinem Intelmanual.
8
Lowlevel-Coding / Re: Eigene Codepage im eigenen OS
« am: 01. June 2013, 04:16 »
http://pastebin.com/qnWF2JGL ist eh die beste Codepage von allen. Und ist mit 60 Bytes auch noch sehr sparsam!
9
Offtopic / Re: Logisim CPU
« am: 15. April 2013, 19:30 »
Ich persönlich hab da noch die PID, die PPID und die PGID drin, aber na ja…
10
Lowlevel-Coding / Re: ARM-Assembler
« am: 06. April 2013, 12:08 »
Ich habe mal von irgendeinem FASM-ARM gehört, aber ich sehen keinen Grund, für ARM nicht GAS zu benutzen – die Syntax ist die Default-ARM-Syntax.
11
Offtopic / Re: Bis wann ist ein OS ein OS?
« am: 23. February 2013, 21:37 »
Das impliziert, dass nur das BIOS dazu in der Lage ist und lässt die Möglichkeit außer acht, dass außerdem noch dir vollkommen unbekannte Software auf einem versteckten Kern im Prozessor laufen könnte. Oder so.
12
Lowlevel-Coding / Re: Global Descriptor Table
« am: 17. February 2013, 20:50 »
Normalerweise will jeder Task seine Segmente dynamisch vergrößern, für Heap und so. Irgendwann kommen sich Segmente dadurch zwangsläufig in die Quere und dann beginnt der Spaß, da muss man die im Speicher hin und her schieben, dabei immer alle Datei mitkopieren, die Deskriptortabellen anpassen (sei es GDT, sei es LDT)…
Das Problem hat man mit Paging halt nicht, weil lineare Adressen nichts mit den physischen¹ zu tun haben. Die virtuellen Adressen der Segmentierung hingegen haben durchaus was mit den linearen² zu tun, weil sie kontinuierlich abbilden, von einer Basisadresse eine bestimmte Anzahl Bytes. Deshalb kann da überhaupt irgendwas kollidieren.
Das heißt auch, wenn man einem Programm ein Segment zuweist, dann muss der dahinter liegende physische Speicher auch tatsächlich existieren. Das ist bei Paging natürlich ganz anders, da muss vom gesamten Adressraum im Prinzip gar nichts physisch da sein (weil der Adressraum ja aus vielen einzelnen Segmenten (den Pages) besteht, die jeweils entweder da sind oder nicht). Man kann das gleiche Prinzip bestimmt auch bei Segmentierung anwenden, nur heißt das dann natürlich, dass jedes Programm ganz viele Segmente bekommt (bspw. für jedes Objekt eins). Und da hat man dann viel Spaß, einen Compiler zu finden, der so ein Speichermodell unterstützt.
tl;dr: Mit Segmentierung hat man nur Ärger, weil man entweder nicht mal eben irgendeinem Programm mehr Speicher zuweisen kann (bestimmt gibts noch andere Gründe), oder zumindest keinen Compiler findet, der sie unterstützt, wenn man sie ordentlich machen will.
¹Aus einer virtuellen Adresse wird mit Segmentierung eine lineare Adresse und daraus mit Paging eine physische. „Ohne“ Segmentierung sind also alle linearen Adressen äquivalent zu den virtuellen.
²Ohne Paging sind alle linearen Adressen äquivalent zu den physischen.
Das Problem hat man mit Paging halt nicht, weil lineare Adressen nichts mit den physischen¹ zu tun haben. Die virtuellen Adressen der Segmentierung hingegen haben durchaus was mit den linearen² zu tun, weil sie kontinuierlich abbilden, von einer Basisadresse eine bestimmte Anzahl Bytes. Deshalb kann da überhaupt irgendwas kollidieren.
Das heißt auch, wenn man einem Programm ein Segment zuweist, dann muss der dahinter liegende physische Speicher auch tatsächlich existieren. Das ist bei Paging natürlich ganz anders, da muss vom gesamten Adressraum im Prinzip gar nichts physisch da sein (weil der Adressraum ja aus vielen einzelnen Segmenten (den Pages) besteht, die jeweils entweder da sind oder nicht). Man kann das gleiche Prinzip bestimmt auch bei Segmentierung anwenden, nur heißt das dann natürlich, dass jedes Programm ganz viele Segmente bekommt (bspw. für jedes Objekt eins). Und da hat man dann viel Spaß, einen Compiler zu finden, der so ein Speichermodell unterstützt.
tl;dr: Mit Segmentierung hat man nur Ärger, weil man entweder nicht mal eben irgendeinem Programm mehr Speicher zuweisen kann (bestimmt gibts noch andere Gründe), oder zumindest keinen Compiler findet, der sie unterstützt, wenn man sie ordentlich machen will.
¹Aus einer virtuellen Adresse wird mit Segmentierung eine lineare Adresse und daraus mit Paging eine physische. „Ohne“ Segmentierung sind also alle linearen Adressen äquivalent zu den virtuellen.
²Ohne Paging sind alle linearen Adressen äquivalent zu den physischen.
13
Lowlevel-Coding / Re: Global Descriptor Table
« am: 17. February 2013, 20:15 »In der Implementierung dürfte es ja recht einfach seinDer war gut. Ich wünsche viel Spaß.
14
Offtopic / Re: Screen of Death
« am: 03. February 2013, 06:14 »
Soooo, und ich finde mich auch mal ein. Bei der Kürze meines Kernelzyklus bin ich froh, dass ich immerhin noch zu Exceptions komme, auch wenn mein Rubykernel Emerald darunter bisher noch keine x86-Exceptions versteht.
Also, meine beiden aktuellen Projekte, µxoµcota (bei dem die Fehlermeldung netterweise die gesamte Restausgabe verdeckt):
Und Emerald:
Zu Exceptions reichts zwar noch, zu extravaganten Farben aber nicht mehr.
Also, meine beiden aktuellen Projekte, µxoµcota (bei dem die Fehlermeldung netterweise die gesamte Restausgabe verdeckt):
Und Emerald:
Zu Exceptions reichts zwar noch, zu extravaganten Farben aber nicht mehr.
15
Lowlevel-Coding / Re: ß usw. ausgeben
« am: 02. February 2013, 01:11 »
Fun fact: Das Wiki hat eine Seite dazu. http://www.lowlevel.eu/wiki/Codepage_437
16
Offtopic / Re: UEFI Dualboot Windows + Linux
« am: 27. January 2013, 17:28 »
Das ist keine zum Thema wirklich beitragende Antwort, aber ich habe hier auch ein Z77-MB mit 16 GB RAM (was auch immer der zur Sache tut) und ich habe mich offenbar richtigerweise für BIOS-Emulation und GRUB (Legacy) entschieden. :3
Übrigens auch Arch, aber Windows 7.
Also, gibt es einen speziellen Grund, warum du UEFI willst? Außer, weil es geht?
Übrigens auch Arch, aber Windows 7.
Also, gibt es einen speziellen Grund, warum du UEFI willst? Außer, weil es geht?
17
Lowlevel-Coding / Re: Windowstreiber-Schnittstelle
« am: 18. January 2013, 20:47 »
Na ja, eigentlich wollte ich ja keine Diskussion zu CDI anfangen, aber wenns kein anderer macht…
CDI-Treiber gibt es genau dann, wenn jemand sie geschrieben hat. Da Treiber für von VMs unterstützte Hardware zu schreiben deutlich einfacher ist, ist logisch, weshalb vor allem dafür Treiber existieren. Zu sagen, CDI habe deshalb diese Zielgruppe, ist aber falsch. CDI hat keine Zielgruppe. Echte Hardware zu unterstützen ist mindestens genauso wichtig wie virtuelle.
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.
CDI-Treiber gibt es genau dann, wenn jemand sie geschrieben hat. Da Treiber für von VMs unterstützte Hardware zu schreiben deutlich einfacher ist, ist logisch, weshalb vor allem dafür Treiber existieren. Zu sagen, CDI habe deshalb diese Zielgruppe, ist aber falsch. CDI hat keine Zielgruppe. Echte Hardware zu unterstützen ist mindestens genauso wichtig wie virtuelle.
18
Lowlevel-Coding / Re: Windowstreiber-Schnittstelle
« am: 18. January 2013, 19:18 »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“.
EDIT: Wenn man nach „Linux on L4“ googlet, ist die Seite der TU Dresden da auch der erste Treffer: http://os.inf.tu-dresden.de/L4/LinuxOnL4/overview.shtml
19
Lowlevel-Coding / Re: Treiber gleich Prozess?
« am: 18. January 2013, 19:06 »
In der Tat ist das eine sehr gute Frage, weil du in den zwei Sätzen die drei Hauptkernelarten beschrieben hast:
Zumindest habe ich das bisher so verstanden. Gerade bei Exokerneln erhält man ja selten konsistente Beschreibungen, was das eigentlich sein soll.
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).
Zumindest habe ich das bisher so verstanden. Gerade bei Exokerneln erhält man ja selten konsistente Beschreibungen, was das eigentlich sein soll.
20
Offtopic / Re: Logisim CPU
« am: 02. January 2013, 22:01 »
Als ich mit Kernelentwicklung angefangen hab, wollte ich nur Assembler lernen. Dass es sowas wie Protected Mode oder Speicherverwaltung überhaupt gibt, wusste ich gar nicht.
Gut, Assembler kann ich heute akzeptabel, insofern kann man behaupten, dass ich mein Ziel erreicht habe, aber na ja…
Gut, Assembler kann ich heute akzeptabel, insofern kann man behaupten, dass ich mein Ziel erreicht habe, aber na ja…