Nachrichten

181

Offtopic / GRUB und Open Source

« am: 28. December 2005, 11:56 »

Wird ja nicht dagegen gelinkt, sollte also nicht das Problem sein ...

182

Lowlevel-Coding / SMP testen

« am: 25. December 2005, 20:23 »

Und ich hab immerhin eine CPU mit 2 Kernen.

183

Lowlevel-Coding / DMA

« am: 25. December 2005, 15:39 »

Jep.

184

Lowlevel-Coding / DMA

« am: 25. December 2005, 13:12 »

Also ich glaub sicher nicht mit dem DMA Chip den wir z.B. für die Floppy programmieren.

185

Lowlevel-Coding / Invalid Operand

« am: 24. December 2005, 23:41 »

Ich glaub das soll gerundet sein.

186

Lowlevel-Coding / DMA

« am: 24. December 2005, 22:09 »

Nun, ich glaub sowohl als auch. Ganz alte Geräte konnten wir nur ins erste MB laden, später dann 16MB und da drüber mit dem Standard DMA Chip nie.

187

Lowlevel-Coding / ASMler gesucht

« am: 24. December 2005, 18:38 »

Na ja - wie soll dir der Assembler bei mehreren CPUs helfen? Wobei das nicht uninteressant wär. Ich finde alle Sprachen sind bislang nur sehr mangelhaft für Multithreading geeignet.

188

OS-Design / Spinlocks/Scheduling

« am: 24. December 2005, 00:16 »

Nun, da hab ich mal die Frage - wieso ändert der Scheduler da was?

Und evtl. könnte man ja verschiedene Listen per Prozessor haben. Dann hilft auch das IRQ abschalten wieder was, wenn ich jetzt nichts übersehe.

189

OS-Design / Kommunikation zwischen Modulen

« am: 24. December 2005, 00:14 »

Doch, so wie joachim_neu es beschrieben hat stimmt es.
Das Ergebnis des JIT-Schrittes kann genauso gut sein, kommt auf die Anzahl der durchgeführten Optimierungen an. Jede Optimierung kostet Zeit, das ist ein Problem. Deswegen lohnt es sich nicht Code der nur einmal durchlaufen zu kompilieren.

Theoretisch hat ein JIT Compiler mehr Möglichkeiten zu optimieren.
Sun's VM ist bei Sachen die nur in der VM ablaufen eigentlich gleich schnell, ganz besonders bei mathematischen Berechnungen wie ich es mal in Benchmarks gesehen hatte. Ein grosses Problem wie ich mal gemerkt habe ist das geringe Tempo von JNI in Sun's VM. Und das man die erstmal starten muss. Aber das beheben wir ja!

190

OS-Design / Dinge, Namen, usw.

« am: 23. December 2005, 23:59 »

Tjo ne, ich hatte auch nie vor den Kernel dafür jedes Mal zu ändern. Der Kernel sollte da nur das Framework für sowas anbieten, so dass man dynamisch Klassen hinzufügen.

Und der Benutzer sollte solche Überlegungen nie erst machen müssen.

Und na ja, im Laufe der Zeit ändert sich eine Klassifizierung insofern das es neue Klassen geben wird.

191

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 23. December 2005, 19:36 »

Na ja - um ein Programm zu testen entwickel ich es, kompilier es dann, muss dann Administrator werden um es zu installieren und kann es dann erst ausführen? Und das für jeden einzelnen Build?

Achso, ich dachte man müsste das Teil dann beim Entwickler des OS "registrieren", damit der das in seine Tabelle aufnimmt...

Nun, das wär dann halt noch schlimmer.
Ich glaub der Teil lohnt sich nur für System auf denen nicht entwickelt werden soll. Kurz um, ich glaub Entwickler werden sowas abschalten müssen.

192

OS-Design / Kommunikation zwischen Modulen

« am: 23. December 2005, 19:31 »

Ich habe bisher noch kein SharedMemory. Aber die Unsicherheit der anderen Mittel "rechtfertigt" nicht die Unsicherheit des eigenen Mittels, oder? Ist so ein Compiler nicht irre aufwendig?

Interessant wird so eine Überlegung erst wenn man sagt: "Angenommen da ist ein Bug, gibt es noch etwas anderes was eine grössere Katastrophe verhindert." In diesem Falle bei allen Fragestellungen (Compiler, Shared Memory, Buffer overflow) nichts. Wenn es eine andere Möglichkeit dann jedoch gibt die dann noch etwas Schutz hat, dann kann man darüber mal nachdenken.

Einfach mal ein "Toll, wenn da ein Bug ist ..." in den Raum zu werfen bringt nicht viel.

So ein Compiler ist schon etwas aufwendiger - dafür kann man sich jedoch andere sehr aufwendige Dinge durchaus sparen, wie z.B. getrennte Addressräume einzurichten und dann wieder eine Kommunikation zwischen diesen zu ermöglichen.

Und wie SSJ7Gohan schon gesagt hat, damit erspart man sich eine gigantische Menge an Bugs in anderen Teilen des Gesamtsystems ...

193

OS-Design / Dinge, Namen, usw.

« am: 23. December 2005, 19:26 »

Nun, irgendwann wird man z.B. einen Player wie Winamp schreiben wollen. Will man sein System nicht auf eine einzige Soundkarte beschränken muss der Player sich eine (oder mehrere) Karten aussuchen, wobei er hierfür wissen muss welche Karten überhaupt vorhanden sind.

Daher muss man auf irgendeine Art alles klassifizieren, ob man nun wie bei dir z.B. alle Diskettenlaufwerke mit fdd* als Prefix versieht oder auf andere Weise.

Deswegen geht es ohne solche Möglichkeiten sicher nicht gut.

194

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 23. December 2005, 12:46 »

Na ja - um ein Programm zu testen entwickel ich es, kompilier es dann, muss dann Administrator werden um es zu installieren und kann es dann erst ausführen? Und das für jeden einzelnen Build?

195

OS-Design / Kommunikation zwischen Modulen

« am: 23. December 2005, 12:32 »

Naja, meine Module werden von einem JIT Compiler kompiliert und wie alle Java/Bytecode Anwendungen in Ring0 ausgeführt. Ring3 Programme werden nur aus Kompitibilitätsgründen unterstützt.

Ist das nicht verdammt unsicher? Wenn in deinem Compiler ein Bug drinn ist, könnte man damit ordentliche Ausfälle provozieren...

Wenn in deinen Routinen zum Shared Memory ein Bug drin ist kann ich bei dir evtl. Daten von anderen Prozessen, wenn in deinen Kernel Routinen ein Buffer Overflow drin ist kann ich Code auf Ring 0 ausführen, usw.

Von der Sicht aus ist es nicht unsicherer als andere Konzepte.

196

OS-Design / Statt C++ mit C#?

« am: 23. December 2005, 12:30 »

Jop, heutzutage ist verdammt viel für die CPU schon ein RAM Bereich und ein paar I/O Ports und noch IRQs.

197

OS-Design / Dinge, Namen, usw.

« am: 23. December 2005, 12:29 »

Nun, beim Enumerieren welche Hardware eines bestimmten Types da ist.
Klassifizieren muss man sowieso, und dynamisch Verzeichnisse anlegen geht wohl.
fdd* zu Matchen wirkt für mich nicht soo sauber. Erinnert mich etwas an die Handhabung mit Device Files unter Linux.

198

OS-Design / Dinge, Namen, usw.

« am: 22. December 2005, 17:11 »

Hmm, dynamisch erstellt wird natürlich nötig sein. Aber ich denke eine Hierarchie wird wohl doch Vorteile bieten.

199

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 22. December 2005, 17:00 »

Nun ja, beim Dau könnte ich mir auch Verwirrung vorstellen wenn es mal so (wenn er es normal benutzt) und mal so (wenn er doch mach als "Admin" arbeiten muss) aussieht.

200

Lowlevel-Coding / Memberfunktionen in C++ übergeben

« am: 20. December 2005, 00:43 »

Oder du schreibst dir schnell ne Routine zur numerischen Integration selber ... oder kann die was besonderes?