Nachrichten

101

Lowlevel-Coding / Re: Prozessorarchitektur

« am: 07. January 2015, 02:15 »

Definiere "effektiv", dann kann man vielleicht auch sinnvoll drüber diskutieren. Code ausführen tun sie alle - und du hast zumindest MIPS und SuperH vergessen.

102

Offtopic / Re: Weihnachten 2014

« am: 07. January 2015, 02:10 »

Auch von mir - wenn auch rückwirkend.

103

Lowlevel-Coding / Re: Sofortige Tastaturinterrupt nach Aktivieren der Hardwareinterrupts

« am: 02. December 2014, 00:03 »

Ok danke, das heißt ich sollte meien Tasks erstmal eine eindeutige ID zuweisen...

Nein, ich meinte damit eher, dass es verschiedene Datenstrukturen mit verschiedenen Vor- und Nachteilen gibt.

Mit dem Pointer alleine kommst du klar, wenn du eine doppelt verkettete Liste baust.

104

Lowlevel-Coding / Re: Sofortige Tastaturinterrupt nach Aktivieren der Hardwareinterrupts

« am: 30. November 2014, 19:23 »

Eine Liste musst du durchsuchen, um einen bestimmten Task zu finden. Wenn du ihn kennst - und bei einer einfach verketteten Liste musst du auch den Task davor kennen, bei einer doppelt verketteten Liste nicht - dann kannst du auch Einträge aus der Mitte entfernen.

105

Lowlevel-Coding / Re: Problem bei Physikalischer Speicherverwaltung (Bitmap)

« am: 26. November 2014, 23:03 »

Das heißt irgendwann, kurz nachdem ich die Interrupts aktiviert habe, kommt der erste Timerinterrupt, meine schedule Funktion wird aufgerufen und mein Kernel springt in den Task den ich vorher initialisiert habe. Und dann beim zweiten Timerinterrupt, wird meine schedule Funktion erneut aufgerufen und in den nächsten Task gesprungen. Sehe ich das so richtig?

Ja.

Dann hätte ich noch eine Frage, wozu brauche ich den Eintrag ins TSS und wieso trage ich dort "new_cpu + 1" als ersten Eintrag immer wieder neu ein?

Du machst Software-Multitasking. Das heißt, du hast genau ein einziges TSS, welches du beim Taskwechsel immer wieder neu befüllst und dann der CPU wieder vor die Nase wirfst. (Bei Hardware-Multitasking hättest du stattdessen ein TSS pro Task, und würdest die CPU immer wieder ein anderes aktivieren lassen, wenn du wechseln möchtest.)

106

Lowlevel-Coding / Re: Problem bei Physikalischer Speicherverwaltung (Bitmap)

« am: 26. November 2014, 19:19 »

Der erste Timerinterrupt wird ausgelöst, nachdem du Interrupts aktiviert hast (mit STI), allerdings nicht unbedingt sofort, sondern erst nach einer (für dich) zufälligen Zeitspanne.

107

Lowlevel-Coding / Re: Problem bei Physikalischer Speicherverwaltung (Bitmap)

« am: 22. November 2014, 19:33 »

blöde frage, aber wenn ich versuche die Datei mit #include <stdint.h> einzubinden, bekomme ich einen Kompilierungsfeher dass die Datei nicht gefundne wurde.

Vermutlich kompilierst du mit ungünstigen Compiler-Flags. Wenn da "-nostdinc" drin steht, dann ersetze das mal durch "-ffreestanding".

108

Lowlevel-Coding / Re: Problem bei Physikalischer Speicherverwaltung (Bitmap)

« am: 22. November 2014, 15:52 »

Die Typen uint32_t, int8_t, uintptr_t usw. haben ihren Sinn. Wenn du eine bestimmte Bitbreite brauchst, dann solltest du diese Typen benutzen, und nicht "unsigned long", auch wenn das zufällig die gleichen Typen sind. Aus dem gleichen Grund solltest du diese Typen auch nicht selbst definieren (gilt auch für NULL).

Dein Compiler stellt dir das alles in den Header-Dateien stdint.h und stddef.h bereit. Nutze sie. Die sind auch für Kernelprogrammierung geeignet und enthalten noch ein paar andere nützliche Dinge.

109

Offtopic / Re: intel Dokumente

« am: 21. November 2014, 03:09 »

Vermutlich nicht, denn Englisch ist die Standardsprache für technische Dokumentation (allerdings findet man auch zunehmend Chinesisch in Datenblättern).

110

Lowlevel-Coding / Re: Problem bei Physikalischer Speicherverwaltung (Bitmap)

« am: 18. November 2014, 01:23 »

"-1" als Fehlerwert passt nicht zu "unsigned int" als Datentyp.

111

OS-Design / Re: YourOS

« am: 16. November 2014, 23:09 »

Du kannst den Stack mit einem Bitmuster, z.B. 0x55aa füllen.
Wenn du dann irgendwann reinguckst, siehst du, bis zu welcher Stelle dieses Muster noch da ist und ab wo es überschrieben wurde.

112

OS-Design / Re: YourOS

« am: 15. November 2014, 02:00 »

Blöde Frage, aber sind die CPU-Caches nicht sowieso immer aktiviert?

113

Lowlevel-Coding / Re: [Anfänger] Tastatur Implementierungs Tipps / Hilfestellung

« am: 10. November 2014, 01:24 »

Was macht jetzt aber register_intr_handler ?
Also soweit ich das verstehe müsste die Funktion ja den intr_stub 33 mit der Funktion irq_handler verknüpfen oder ?
Also muss sozusagen in dem Handler der in Tutorial 5 erstellt wurde für 0x21 die Funktion irq handler gesetzt werden oder sehe ich das falsch?

Die Funktion register_intr_handler() verklebt in deinem OS den Interrupt 33 mit einer bestimmten Funktion. Für den Anfang reicht es, wenn du einfach den Funktionsaufruf in dein handle_interrupt() einträgst, aber später möchtest du eher eine dynamische Lösung, wie z.B. das von Jidder beschriebene Array, haben.

Achso, und Herzlich Willkommen auch von mir!

114

Lowlevel-Coding / Re: Problem bei Physikalischer Speicherverwaltung (Bitmap)

« am: 06. November 2014, 17:54 »

Du kannst deiner physischen Speicherverwaltung (nicht physikalische, aber ich mach' den Fehler auch immer mal wieder...) auch beibringen, mehrere aufeinanderfolgende Seiten zu besorgen. Auf dem PC ist das für das Diskettenlaufwerk noch halbwegs sinnvoll, sonst braucht man das aber eigentlich nicht mehr. (Außerhalb der Welt von x86 ist das noch anders.)

115

Lowlevel-Coding / Re: Problem bei Physikalischer Speicherverwaltung (Bitmap)

« am: 06. November 2014, 14:49 »

Wenn ein Programm sagt "ich will 4 MB Speicher", dann ist normalerweise eine Bibliothek dafür zuständig, diese 4 MB Speicher zu besorgen und sich zusätzlich zu merken, wieviel Speicher das für diesen Block war. Diese Bibliothek besorgt sich also diese 4 MB Speicher (und wahrscheinlich sogar etwas mehr für die Verwaltung) vom Kernel.

Im Kernel sitzt die virtuelle Speicherverwaltung, die dann 4+ MB Speicher finden muss und auch in den Prozess mappen muss, damit der auch Zugriff darauf hat. Dazu benutzt sie wiederum die physikalische Speicherverwaltung, indem sie genug einzelne Pages (die normalerweise nicht zusammenhängen müssen!) anfordert und zu einem großen virtuellen Block zusammenschweißt.

Deine physikalische Speicherverwaltung weiß davon nichts. Die sieht im Zweifelsfall nur über tausend einzelne Anfragen vom Typ "gib mir eine freie Page, egal welche" und kann das nicht mehr zu irgendwelchen Blöcken zuordnen.

116

Lowlevel-Coding / Re: GCC Fehler

« am: 29. October 2014, 03:10 »

Ich würde die ganzen -I"/pfad/zum/src/Kernel/xxx" zu einem -I"/pfad/zum/src/Kernel" zusammenfassen und dann die Headerdateien mit #include <xxx/header.h> einbinden. Alternativ könntest du statt Anführungszeichen auch spitze Klammern probieren. Allerdings bezweifle ich, dass das an deinem Problem etwas ändert.

Möglicherweise bessert sich was, wenn du -nostdinc weglässt und dich nur auf -ffreestanding verlässt...

117

Lowlevel-Coding / Re: C-Kernel mit GRUB

« am: 15. October 2014, 14:04 »

Ich will meinen Bootloader nicht ersetzen, nur GRUB Legacy haben um die Konsole starten zu können. Reicht es dazu, wenn ich

Code: [Auswählen]

sudo apt-get install grub eingebe?

Das hängt von deiner Linux-Distribution ab. Unter Debian/Ubuntu würde es funktionieren, wenn der grub legacy noch in den Paketquellen verfügbar wäre. Ist er aber seit längerem nicht mehr, weil er durch Grub 2 ersetzt wurde.

118

Offtopic / Re: Besonders kompartible Tablets?

« am: 26. August 2014, 03:07 »

Meiner Meinung nach sind Tablets wunderbar zum Konsumieren von Inhalten geeignet, aber nicht, um Inhalte zu produzieren. Das merkt man auch, wenn man sich mit Android und dem Angebot an Apps etwas auseinandersetzt: Die Zielrichtung ist da eher eindeutig. Ich war jedenfalls sehr enttäuscht und nutze das Tablet nur zum Spielen oder PDFs gucken.

Effektiv gibt es nur drei Kategorien von Tablets: iPad, Windows und Android. Wenn du am System pfuschen können willst, willst du ein rootbares Android-Tablet (nicht bei jedem ist das möglich) oder eines, bei dem man eine alternative Firmware drauf machen kann (z.B. Cyagenmod). Ich weiß aber nicht, wie aktuell das alles noch ist - angeblich sollen Mods mit neuen Androids nicht funktionieren? Bin da nicht auf dem neusten Stand. Zu den Windows-Tablets kann ich nichts sagen, habe noch nie eins bewusst gesehen.

Ansonsten unterscheiden die sich - wie Computer - nur in Ausstattung, Geschwindigkeit, Qualität, Preis und mitgeliefertem Müll (den man bei Tablets oft nicht deinstallieren kann).

119

Offtopic / Re: NSA und die Sicherheit von Betriebssystemen

« am: 24. August 2014, 02:26 »

Der Beitrag, den du zitierst, war über ein halbes Jahr alt.

Ich unterstelle allen Geheimdiensten, für alle einigermaßen verbreiteten Betriebssysteme genug Sicherheitslücken vorbereitet zu haben, um damit ihre Aktionen machen zu können, unabhängig vom der Offenheit des Quellcodes. Allerdings bin auch ich der Meinung, dass US-Software anfälliger für Angriffe per Gesetzestext ist, und Linux ist nicht per se amerikanisch (allerdings auch nicht finnisch).

Hyperboria klingt interessant. Tor klang auch mal interessant. Mal schauen, ob sich das verbreitet (und ob es trotz Verbreitung in der Lage ist, Angriffen von innen und von außen zu widerstehen). Ich fürchte, dass die im Augenblick sicherste Variante darin besteht, das Internet als Ganzes zu umgehen. Vorteilhafterweise gibt es Alternativen, nachteilhafterweise sind diese meist reguliert und daher nicht anonym. Dafür sind sie resistenter gegen Abhören und unendlich langsam.

120

Offtopic / Re: NSA und die Sicherheit von Betriebssystemen

« am: 22. August 2014, 02:28 »

Sicher, dass Tor nicht von Anfang an eine Sache des US-Militärs war?

"Hindsight is 20/20."
Mich hat man ja grundsätzlich als Spinner abgetan, wenn ich dazu mal was gesagt habe (natürlich nicht überall), aber jetzt kommen alle aus ihren Löchern mit "aber das wusste doch jeder schon immer!!".