Nachrichten

21

OS-Design / Re: Verwaltung von Threads

« am: 30. September 2012, 04:47 »

Ok, mein momentaner Plan sieht so aus, dass ich zwei doppelt-verkettete Listen für den Scheduler benutze. Eine mit laufenden Threads, die andere mit den blockierten. Die Listen beinhalten im Grunde nur einen Pointer, der auf die Thread-Struktur im Baum zeigt.
Um das ganze schön sauber zu halten, habe ich in den letzten Tagen an der Implementierung einer solchen Liste gebastelt und mich dabei grob an std::list aus C++ orientiert. Genau übernehmen geht ja nicht, da ich meinen Kernel ja in FreeBASIC schreibe.
Meine Liste kann momentan folgendes: push_front, push_back, pop_front und pop_back, dazu noch Konstruktor & Destruktor und das Überladen von new und delete, damit das ganze auch im Kernel klappt. Dazu hab ich noch einen Datentyp namens list_iterator gebaut, der grob C++-ähnliche Funktionen bereitstellt. Mit list.begin() und list.ending() kann ich mir dann so einen Iterator holen und mit list.remove() kann ich das Element an der Position des Iterators entfernen.
Ich denke dass es mir damit möglich sein sollte einen vernünftigen Scheduler zu bauen, und genau das werde ich dann wohl in den nächsten Tagen in Angriff nehmen.

@Dimension: Dein Vorschlag klingt auch sehr interessant. Das wäre ja dann im Endeffekt eine Verschmelzung der beiden Verwaltungsstrukturen zu einer einzigen. Bei richtiger Umsetzung würde mir das ein kmalloc() bei der Erstellung eines Threads ersparen. Eventuell werde ich auf diese Idee zurückgreifen, vor allem falls sich mein bisheriger Ansatz als zu langsam erweisen sollte (FreeBASIC ist nicht gerade ein Rennpferd, aber was solls).

Grüße,
TheThing

22

OS-Design / Re: Verwaltung von Threads

« am: 24. September 2012, 20:34 »

Ah, vielen Dank für die Antworten.

tyndur hat logischerweise diese Zuordnung von Threads zu Prozessen (in beide Richtungen, d.h. Threads haben einen Pointer auf ihren Prozess und Prozesse eine Liste von ihren Threads), aber das heißt ja nicht, dass der Scheduler diese Datenstrukturen direkt benutzen muss.

Hm, das klingt nach einer guten Idee. Was mir aber daran irgendwie nicht gefällt ist, dass ja dann jeder Thread in zwei Listen steht, einmal in der Liste des Prozesses und einmal in der Liste der Threads. Aber scheinbar bleibt mir ja da nichts anderes übrig.

@MNemo: Das klingt gut. Ich denke ich werde es so (oder so ähnlich) umsetzen.

23

OS-Design / Verwaltung von Threads

« am: 24. September 2012, 04:53 »

Hi,
so nach dem Abitur und vor dem Studium hat man ja doch relativ viel Zeit... Daher bin ich auch mal wieder über meinen Kernel bzw. mein OS gestolpert. Der einfachheit mal schnell ein Debian Wheezy in einer VM aufgesetzt, repository geklont und los ging der Spaß.
Dann erstmal jede Menge alte Debugging-Ausgaben entfernt, am Paging-Code geschraubt und mal wieder an der Überarbeitung des Multitaskings gebastelt. Dabei fiel mir folgendes auf: Ich habe zwar die Verwendung von Threads vorgesehen, allerdings ruft mein Scheduler die Threads stumpf nacheinander auf. Da Threads evtl. blockiert sein können, ist das nicht wirklich schön. Nachdem ich dann eine Weile rumprobiert hatte, kam ich zu dem Schluss, dass es ziemlich unpraktisch ist, wenn mein Scheduler versucht, eine Art Baumstruktur abzuarbeiten (Es gibt eine Linked-List mit Prozessen, jeder Prozess enhält eine Linked-List von Threads).
Daher stellt sich mir die Frage: Wie könnte man das besser lösen? Ich habe mir dazu bisher nur tyndur-Code angesehen. Der "alte" Kernel kann ja keine Threads, daher habe ich mir Kernel2 mal angesehen. Da komme ich allerdings nicht so ganz mit. Es werden ja scheinbar Listen genutzt, die der Scheduler stumpf durchlaufen kann. Allerdings gibt es da zwei Listen (threads_available und threads_scheduled). Wofür genau sind die zwei da, und wie werden sie benutzt?

Eine kleine Idee die ich gerade hatte (vielleicht macht Kernel2 das ähnlich?):
Ich nehme zwei Linked-Lists, in der einen hängen alle Threads, die zweite ist leer. Der Scheduler fängt dann an, aus der ersten Liste Threads zu nehmen. Ist der Thread lauffähig, wird er ausgeführt, wenn nicht, wandert er gleich in die zweite Liste. Ist ein Thread durchgelaufen, wandert er auch in die zweite Liste. Wenn die erste Liste leer ist, wird dann getauscht.
Allerdings stellt sich mir da noch eine Frage: Meine momentanen Verwaltungsstrukturen sind ja Baum-mäßig. Wenn ich jetzt Threads einfach in Listen lege, geht mir ja diese klare Zuordnung (Thread gehört zu Prozess) verloren. Wie soll ich dann die Prozesse effizient verwalten? Z.B. wenn ein Prozess gekillt werden muss.

Daher möchte ich hier mal wieder um Rat fragen. Welcher Ansatz ist da vernünftig? Was verwenden andere OS, um dieses Problem zu lösen?

Grüße,
TheThing

24

OS-Design / Re: In welcher Reihenfolge (Paging, Multitasking, VFS, ..)

« am: 19. July 2012, 17:23 »

Bei mir lief das auch so, meinen ersten Kernel hab ich weggeworfen, den zweiten baue ich momentan um. Meine Reihenfolge war folgende: Textausgabe (für Debugging), GDT, PIC, IDT, PIT, PMM. Dann kam Multitasking und dann Paging, wobei ich da bemerkt habe, dass mein bisheriger Code Unsinn ist. Also habe ich mir einen Heap-Manager gebaut, in den nur noch entsprechende vmm-Funktionen eingesetzt werden müssen. Und ich baue momentan Multitasking und Paging gleichzeitig um. Aber es könnte sein dass diesmal aus dem Kernel etwas brauchbares wird

25

Offtopic / Re: Welchen Desktop benutzt ihr?

« am: 12. July 2012, 21:21 »

Also ich bin KDE 4 User da mir Gnome von der Benutzung her einfach nie zugesagt hat. Vor KDE 4 hatte ich natürlich KDE 3. Gnome 3 hatte ich auch mal ausprobiert, kam aber kein bisschen damit klar. Cinnamon fand ich zwar schon besser als Gnome 3, gefiel mir aber auch nicht so richtig.
Auf meinem Notebook läuft netrunner mit KDE 4, momentan habe ich aber auch auf meinem Desktop-Rechner eine Debian VM mit Xfce und xdm, die ich im Seamless-Mode von VirtualBox laufen hab.

26

Offtopic / Re: Hosen runter! Zeigt eure OS ;)

« am: 09. July 2012, 01:12 »

*etwas Staub vom Thread abklopf*
Eine Schande, dass dieser Thread so eingestaubt ist. Na los, postet mal wieder was

Ich gehe sogar mit gutem Beispiel voran:
Obwohl ich ja die Weiterentwicklung meines OS in letzter Zeit arg hab schleifen lassen, so gab es doch kürzlich wieder einige Updates für den experimental-branch. Darunter befindet sich nun auch ein neuer Heap-Manager, der zwar die Vergrößerung und Verkleinerung des Heaps zur Laufzeit noch nicht unterstützt, jedoch ansonsten super funktioniert. Nach Stunden des Debuggings beherrscht dieser Manager nun die Verwaltung von beliebig vielen Speicherblöcken, die er in einer Freispeicherliste unterbringt. Dafür benutze ich eine Doppelt verkettete Liste, die den eigentlich freien Bereich innerhalb eines freien Blocks für zwei Pointer benutzt und damit keinen "externen" Speicher für die Verwaltung benötigt. Das Splitten von Blöcken funktioniert genauso wie die Vereinigung von freien Blöcken (left- und right-unification).
Grob orientiert hab ich mich dabei am Heap-Tutorial von James Molloy, allerdings habe ich eben die Verwaltung der Blöcke anders gelöst als er.
Daher nun ein Screenshot meines Kernels, der zunächst zwei Speicherbereiche reserviert, sie wieder frei gibt und dann einen neuen reserviert. Wie leicht erkennbar ist, funktioniert das sogar:


Als nächstes steht dann ein rewrite des Multitasking-Systems an, welches dann threadbasiert sein soll. Danach gibts dann irgendwann IPC und das Starten der von GRUB 2 übergebenen Module. Und natürlich muss der Page Fault noch raus, denn ich bekomme, wenn ich in der jetzigen Version paging einschalte

27

tyndur / Re: Status von LOST

« am: 04. July 2012, 17:54 »

Naja, nachdem mir aptitude bei der Installation von wine das halbe System deinstallieren wollte, traue ich der Kiste nicht mehr Aber ich denke ich werds mal probieren...

28

tyndur / Re: Status von LOST

« am: 03. July 2012, 01:35 »

Jay, gibts dazu vielleicht auch ein fertiges build? Ich bin gerade etwas zu faul týndur unter Linux selbst zu bauen, außerdem vermute ich, dass bei mir wieder irgendwas nicht funktionieren wird. Zum einen da ich ein Pechvogel bin und weil die Leute von Canonical wohl in letzter Zeit gerne mal Bugs nach kubuntu bringen. 

29

Softwareentwicklung / Re: Linkeroptimierung

« am: 17. June 2012, 20:47 »

Zu diesem Thema habe ich erst kürzlich eine PDF gefunden: http://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf

30

Softwareentwicklung / Re: GCC Funktionen in Header "undefined reference"

« am: 04. April 2012, 15:48 »

Exakt, DOSBox sorgt nämlich für eine echte DOS-Umgebung, was cmd nicht tut und ntvdm eher schlecht getan hat. Und als DOS-Box (meistens mit Bindestrich dazwischen) bezeichnen viele Menschen cmd.exe, was ja falsch ist
Ich merke, das wird gerade ein bisschen OT hier

31

Softwareentwicklung / Re: GCC Funktionen in Header "undefined reference"

« am: 04. April 2012, 15:41 »

Der Vollständigkeit halber: Der DOS-Kram von NT hieß "ntvdm" (NT Virtual DOS Machine). Und er war furchtbar. Leider wird häufig cmd.exe immer noch fälschlicherweise als "DOS-Box" oder ähnlichem bezeichnet. Außer dem halbwegs ähnlichen Äußeren und der konzeptbedingt ähnlichen Bedienung haben cmd.exe und echtes DOS jedoch herzlich wenig gemeinsam.

32

Softwareentwicklung / Re: Welche Compiler

« am: 11. February 2012, 15:58 »

Was muss den eine Gute IDE können, so was wie FBEdit? Ich hab mit der Kombination FreeBasic und Geany unter Linux eigentlich keinen Probleme. Eventuell musst du Autovervollständigungsbeschreibungen FreeBasic-Configurationsdatei ändern, aber sonst.

Naja, Geany geht, ich fühle mich halt einfach nicht wohl damit. Ich bevorzuge eigentlich FBIde aber unter wine macht das irgendwie keinen Spaß. Es gab vor einiger Zeit ein vielversprechendes IDE-Projekt mit Linux-Port, scheint aber nicht mehr weiterentwickelt zu werden.

Und jetzt genug OT

33

Softwareentwicklung / Re: Welche Compiler

« am: 26. January 2012, 13:51 »

Wenn VBox Probleme mit "push gs" hatte, klingt das eher nach einem komplexeren Problem in deinem Code. Schließlich funktionieren fast alle anderen x86/x86_64 OS in VBox (einzig tyndur brauchte ein "nodma"), die Wahrscheinlichkeit ist daher ziemlich gering, dass es an VBox liegt.
Ich hatte mit VBox trotz umfangreicher Nutzung nie Probleme (hab sogar neulich mit nem Server in VBox auf einem Rechner über PXE Ubuntu installiert) und kann es daher auch empfehlen. Zum Debuggen ist VBox natürlich nicht das Gelbe vom Ei, aber das ist ja klar.

@stultus: Ich blieb damals unter Windows aus zwei Gründen: Zum einen ist 90% meiner restlichen Software Windows-spezifisch, bei einem Großteil davon handelt es sich um Spiele, die unter wine nicht vernünftig laufen. Zum anderen gab (und gibt) es keine gute IDE für FreeBASIC unter Linux. Wobei bei mir jetzt Geany als Notlösung herhält.

34

Softwareentwicklung / Re: Welche Compiler

« am: 25. January 2012, 11:13 »

Ich habe früher mein OS auch immer in einer VM kompiliert. Ich fand das früher aber ziemlich eklig die Code-Files in die VM zu kriegen und das Kompilat wieder raus.
Da ich mittlerweile git benutze und auch ein Notebook mit Linux mein eigen nenne geht das jetzt besser
Ich habe mich damals für Linux entschieden da ich dort am wenigstens Aufwand mit der Umgebung hatte (ELF wird unterstützt, ich hab direkt gcc) und ich sowieso Linux mehr mag. Letztendlich ist die Frage nach dem Compiler und dem OS Geschmackssache.
Das mit der Geschwindigkeit bei MinGW stimmt, im Vergleich zum Linux-gcc ist es sehr langsam. Selbst gcc auf meinem P4 mit 2.8 GHz schlägt den MinGW auf meinem Core 2 um Längen. Das hat eben damit zu tun dass gcc eigentlich für eine POSIX-Umgebung ausgelegt ist und unter Windows da jede Menge Kompatibilitätskram dazwischenhängt.
Noch langsamer ist bei mir mingw64, sowohl in der 32- als auch in der 64-Bit Version (ich benutze ein personal build von gcc 4.6.2 mit std::thread-Unterstützung aufgrund eines anderen Projektes von mir). Die erzeugten Programme jedoch sind bei allen drei Varianten bei mir schneller als mit VC++ erzeugte.

Je nach Geschmack kommen in diesem Fall also entweder eine VM mit Linux+gcc oder ein Cross-MinGW infrage. Ich bevorzuge Linux+gcc, aber das ist eine Entscheidung die man selbst treffen muss.
In Sachen Assembler fiel meine Wahl auf nasm. Manche mögen vielleicht schief gucken, weil ich unter die gcc-Familie nasm mische, aber ich kam mit nasm bisher super klar und es war auch der erste den ich je benutzt habe.

35

OS-Design / Re: GUI LowLevel

« am: 06. January 2012, 15:16 »

Du sprichst also vom fertigen Code, der dann auf der GPU läuft? An den komme ich per WebGL doch gar nicht ran.
Bei normaler Software ist das wieder was anderes, da kam mit OpenGL 4 (.2 ?) gerade die Möglichkeit, die fertigen Shader vom Treiber abzuholen und später wieder zu laden, um zeitaufwändiges neu-kompilieren beim Programmstart zu verhindern

36

OS-Design / Re: GUI LowLevel

« am: 05. January 2012, 17:43 »

Ich sehe den Thread gerade eben erst, und möchte nochmal bei den Shadern einhaken.
Ich weiß jetzt nicht, wie das bei D3D aussieht, aber GLSL-Shader können nicht einfach auf irgendwelchen RAM zugreifen.
Ein Beispiel: http://pastebin.de/21920
Der Shader bekommt seine Daten entweder aus Buffern, die vorher von der Anwendung (und dadurch vom Treiber) an die "in-Variablen" gebunden werden (die bekommt der Shader per Vertex) oder per uniform (Daten per Render-Call). Das Weiterreichen von Daten innerhalb der Shader erfolgt mit out/in, die Ausgabe kommt per out entweder in den Framebuffer oder in Multiple-Render-Targets (muss vorher von der Software gebunden werden).
So etwas wie Pointer o.Ä. kennt die Sprache gar nicht, der Zugriff auf Daten erfolgt in einem sehr engen Rahmen.
Von daher scheinen mir diese Entrüstungen, die es über WebGL und Shader gab, ziemlich übertrieben.

37

Lyrisches Eck / Re: Frohes Fest

« am: 26. December 2011, 00:48 »

Frohe Weihnachten auch von mir

38

OS-Design / Re: Wie geht ihr an die Entwicklung eures OS heran?

« am: 19. December 2011, 19:43 »

Einige schreiben das OS in C weil sie auf C schwören, andere in C++ weil ihnen das objektorientierte Paradigma gefällt, andere wiederrum schreiben in Pascal weil es etwas anderes ist, andere schreiben in Assembler weil sie denken ihr OS kann nur so viel schneller sein als Windows 7.

Andere schreiben ihr OS in FreeBASIC, weil sie einen Dachschaden haben 

Ich gehöre auch eher zu der Fraktion, die weniger plant und mehr bastelt. Ich hab auch schon einen Kernel weggeschmissen, habs aber nicht bereut, denn ich habe daraus gelernt und die Fehler bei meinem zweiten vermieden.
Ich denke aber, dass jeder so seine eigene Herangehensweise hat und haben sollte. Grundlegende Entscheidungen sollte man aber vielleicht vorher treffen z.B. Microkernel oder Monolith (wie DerHartmut schon sagte). Die beste Lösung für manch andere Dinge sieht man erst, wenn man beim basteln erkennt, welche Anforderungen gestellt werden.

Ansonsten habe ich festgestellt, dass Abwechslung sehr hilfreich ist. Momentan z.B. habe ich zwar mein kmalloc grob geplant, habe aber gerade keine Lust, es umzusetzen, also habe ich mich wieder meiner Game-Engine gewidmet. So hab ich für eine Weile keinen OS-Kram im Kopf und kann später mit frischer Motivation weitermachen.
Wobei da eins wichtig ist: Kommentare. Man sollte seinen Code nicht "überkommentieren", aber komplexe Stellen etwas zu beschreiben/erklären schadet nie und hilft sehr, wenn man nach einiger Zeit mal wieder in den Code sieht.

39

Offtopic / Re: Umstellung auf Winterzeit mit Se7en

« am: 26. October 2011, 15:34 »

Das Feature gibt es mindestens schon seit Windows ME...

PS: Für alle Linux-User: Die Sommerzeit endet um 3:00, am Sonntag, dem 30. 

Und wie kommst du auf die Idee, dass "Linux-User" das wissen müssten? Glaubst du, die grafischen Oberflächen für Linux hätten so ein Feature nicht?

40

Das Wiki / Re:Übertreibung(en)

« am: 22. July 2011, 00:49 »

Wenigstens ist mein OS das fortgeschrittenste Projekt in FreeBASIC (Nein, das ist keine Aufforderung an euch ein besseres zu machen )
Ein gesunder Optimismus (also nix für mich) mag ja nicht schaden, aber manche unrealistische Äußerungen tragen durchaus zur Belustigung bei ^^