Themen

1

Offtopic / Das Lowlevel-Wiki bekommt eine Lizenz

« am: 22. March 2008, 19:20 »

Mehr Informationen dazu gibt es hier. Ich w�rde mir w�nschen das m�glichst viele derer die bereits �nderungen in der Vergangenheit vorgenommen haben, der Lizenz zustimmen.

Edit: Wenn eine Mehrheit f�r by-sa ist, dann ist das auch akzeptabel. Wir waren nur der �berzeugung, dass sich diese Mehrheit sehr wahrscheinlich nicht finden wird, deswegen by-nc-sa.

2

Offtopic / Urheberrecht im wiki

« am: 20. June 2007, 11:38 »

hi,

ich würd mich sehr freuen wenn wir uns fürs wiki auf eine Lizenz einigen würden, denn diese Copyrights (da ist es mir halt grad aufgefallen, nichts gegen Nos) verursacht bei mir derben Augenkrebs. Versteht mich nicht falsch, aber was bringt es, wenn man sogut wie alle Rechte an einem wiki-Artikel für sich behält? Davon hat doch keiner was.
Ich würd mir wünschen das wir uns auf eine Lizenz einigen, die dann aber auch verpflichtend für das ges. wiki angewendet werden muss (ansonsten gibts ne Löschung). Ich würd einfach mal die GNU Free Documentation License nehmen, da hat jeder Author immernoch ausreichende Rechte (wem das wichtig ist) oder einfach ein Equivalent zu public domain. Bin aber für alle andere Vorschläge offen, hauptsach irgendwas einheitliches bei dem man dann auch den Artikel benutzen, abändern etc. darf.

hf & cu

3

OS-Design / Implementation von RPC

« am: 10. April 2007, 18:53 »

Ich hab mir in den letzten 2 Wochen mal Gedanken zu RPC gemacht und heute eine Implementierung für mein OS geschrieben. Meine Implementierung sieht (mal alle lightOS spezifischen Details weggelassen so aus): Ein thread registriert einen RPC-Handler, welcher von anderen Threads aufgerufen werden kann. Sobald ein RPC-Aufruf reinkommt wird der Registerinhalt des threads, welcher den RPC-Handler registriert hat, gespeichert, ein paar Parameter auf den Stack gepusht und dann beim RPC-Handler mit der Ausführung begonnen. Ist der RPC-Handler fertig werden wird der alte Registerinhalt wiederhergestellt und mit der Ausführung an der alten stelle weitergemacht. (das ist afaik mit der LOST IPC vergleichbar)
Nun hab ich folgendes Problem: Es gibt in jedem Thread bestimmte Bereiche, die atomisch ausgeführt werden müssen, zB best. Teile von malloc, das pushen auf einen vector, das anhängen an eine Liste, etc... Da diese Sachen nicht innerhalb von einer Instruktion geschehen, könnten sie von einem RPC-Aufruf unterbrochen werden. Wenn jetzt aber der RPC-Handler seinerseits eine dieser Funktionen aufruft, dann könnte es krachen, zB könnten Speicherbereiche doppelt alloziert werden, freie Speicherbereiche verloren gehen oder der Zustand der Liste/des Vectors inkonsistent werden. In multithreading anwendungen würde man das über mutex/futex, Semaphore oder Semaphoren regeln, aber das geht in diesem Fall nicht, da bei allen diesen Synchronisationsmethoden die möglichkeit bestehen muss, dass der Codebereich, welcher den Lock hat, solange ausgeführt werden muss, bis dieser Lock wieder frei ist. Da aber der RPC-Handler die weitere Ausführung unterbrochen hat und erst nach dem RPC-Handler die Ausführung dort weitergeht, können oben genannte Methoden nicht verwendet werden ohne das es nicht zu einem Deadlock kommt.
Die einzigen Lösungen die ich sehe:
* spezielle Bereiche des Threads RPC'bar bzw. der umgekehrte Fall nicht-RPC'bar machen => viel Aufwand, portierbarkeit von bestehendem Code?
* RPC-Handler nichts derartiges machen lassen => schränkt zu sehr ein
* Popup-Threads: Für jeden RPC-Call einen Thread erstellen bzw. einen eigenen bestehenden Thread weiternutzen. Dann kann man solche Probleme wieder über die ganz normale Synchronisation von Multithreadinganwendungen lösen.
* Thread Migration: fast das gleiche wie Popup-Thread. Der unterschied ist nur, dass man den aufrufenden thread in den Kontext des aufzurufenden Prozesses verschleppt und dann den RPC-Handler ausführt. Damit spart man sich die Kosten der Threaderstellung, aber dadurch wird die RPC wieder synchron.

Mir gefallen die ersten beiden Lösungen überhaupt nicht und die letzten beiden kann man nunmal auch über message-passing und multithreading lösen ohne soviel aufwand betreiben zu müssen. Fällt evtl. jemandem noch eine andere Lösung ein, wie man RPC realisieren könnte?

4

Offtopic / make

« am: 14. August 2006, 12:57 »

hi,

gibt es irgendeinen Weg den Output von make, wenn man es in Unterverzeichnissen ausführt, etwas zu begrenzen? Ich mein folgende Informationen sind einfach überflüssig:

make[1]: Entering directory `/home/bluecode/programming/lightOS/trunk/lib'
make[2]: Entering directory `/home/bluecode/programming/lightOS/trunk/lib/lightOS'
make[3]: Entering directory `/home/bluecode/programming/lightOS/trunk/lib/lightOS/x86'
make[3]: Leaving directory `/home/bluecode/programming/lightOS/trunk/lib/lightOS/x86'
make[2]: Leaving directory `/home/bluecode/programming/lightOS/trunk/lib/lightOS'
make[1]: Leaving directory `/home/bluecode/programming/lightOS/trunk/lib'

Die Makefiles in den Unterverzeichnissen ruf ich mit

Code: [Auswählen]


make -C subdir target


auf. Wär wirklich ungemein hilfreich, wenn ihr mir helfen könntet. Danke!

5

Das Wiki / Host für wiki

« am: 25. July 2006, 00:16 »

hi,

Gibt es Freiwillige als Host für das wiki? Oder gibt es Vorschläge wo man das wiki hosten könnte? Desweiteren hoffe ich auch auf Vorschläge, welche Software für das wiki benutzt werden soll.

Mit wären RSS Feed und Login wichtig.

6

Offtopic / Suche möglichst einfaches realmode OS

« am: 17. July 2006, 11:35 »

hi,

ich such grad für MyEmu ein einfaches, open-source realmode OS, welches aber folgendes kann:
* Disketten
* irgendein Dateisystem
* PS/2 Tastatur
* evtl. ein paar kleine Programme dabei
Desweiteren sollte es auf keinen Fall auf mehr Hardware als - PIT, PIC, DMA, Floppy, CMOS, PS/2 Tastatur und natürlich den Bildschirm (aber im Textmodus) - zugreifen und wenn möglich all das auch noch über das BIOS machen

Ich weiß, viele Anforderungen, aber ich hoffe ihr könnt mir trotzdem weiterhelfen. Danke

7

Das Wiki / wiki statt magazin (Poll)

« am: 16. July 2006, 14:24 »

Ok, wir diskutieren ja in dem anderen Thread bereits über ein wiki an Stelle des Magazins. Wegen fehlender Initiative anderer und Absenz der meisten Mods, nehm ich einfach mal das Heft in die Hand. Ich hab zwar in dem anderen Thread keine Stimmen gegen das wiki gesehen, aber um das ganze demokratisch zu gestalten (und damit das nicht schon wieder im Sande verläuft) würd ich euch einfach auffordern in diesem Thread für oder gegen ein wiki anstelle des Magazins abzustimmen. Jeder Registrierte hat genau eine Stimme. Ich würde euch bitten einfach nur eure Stimme abzugegeben und eine evtl. Begründung in dem anderen Thread zu posten, damit das zählen einfacher wird. Desweiteren würd ich alle bitten nur einmal in diesem Thread zu posten.
Falls jemand mit dem Thread (oder mir oder was-auch-immer) unzufrieden ist, dann soll er sich bitte bei mir (ICQ oder email) melden und nicht in diesem Thread posten (Wie gesagt, nur Stimmabgaben hier). Danke.

Das ganze wird am So. den 23.07.2006 demokratisch ausgewertet. Falls das ganze aufs wiki hinausläuft, werd ich einen neuen Thread erstellen, um nach jemandem der das wiki hostet zu suchen.

Ich bin für das wiki.

8

Offtopic / The IT Crowd

« am: 24. May 2006, 19:01 »

hi,

kennt ihr die Serie? Die is einfach Hammer. Gibts bei Filecloud zum download. Ist "leider" auf englisch Schade das es davon bis jetzt nur 6 Episoden gibt...

9

Lowlevel-Coding / andere Architektur :?:

« am: 08. January 2006, 19:49 »

hi,

gibt es abgesehen von x86(-64) auch noch andere (Prozessor-)Architekturen, die in PC's in Zukunft verwendung finden Apple wird in 2006/2007 auch auf x86-64 umsteigen.
Ich mein mal ehrlich: Die x86(-64) is doch scheiße (zum OSDeven): DMA-Chips, die nur bis 16MB gehen, aber eingentlich eh keiner mehr brauchen sollte. Adressleitungen die aktiviert werden müssen. Keyboardcontroller, die das System rebooten. Protected-Mode der erst eingeschaltet werden muss. NMI's deren Aktivierung durch das höchste Bit im CMOS Register 0x70 (oder so) steuern lässt. Segmentierung die eh keiner benutzt, aber trotzdem irgendwie mitgeschleppt werden muss. Systemmanagement-Mode der benutzt wird um PS/2 Maus/Tastatur zu emulieren, wenn nur USB Tastatur vorhanden ist. Und immer diese Abfragen, ob dies oder jenes unterstützt wird oder nicht. Das nervt ziemlich.
Warum gibt es keine neue Architektur, die nicht versucht auf Biegen und Brechen abwärtskompatibel zu 8086 zu sein Wer will denn noch DOS Programme nativ ausführen Dafür reicht doch wohl ein Emulator.
Und für alle die noch zweifeln: Ja ich bin von x86(-64) ziemlich angepisst. Des taugt doch nun wirklich net zum OSDev.

Warum gibts keine Architektur die nicht versucht alle Schwächung vorhergegangener Architekturen mitzuschleppen. Und warum braucht man TCPA/Palladium um DoS Attacken zu verhindern Das ausführen von Code (auf dem Stack) würde sich auch einfach durch ein NX Bit auf Page-Ebene verhindern liese

Fühlt euch bitte nicht angegriffen,
falls ihr glühende Verfechter von x86(-64) seit.
Ich müsste einfach mal meinen Frust rauslassen