Nachrichten

541

Lowlevel-Coding / Re:SMP und die damit verbundenen Probleme

« am: 28. October 2010, 22:50 »

Ich habe mal ein wenig gegooglelt. Bin jetzt zwar ein wenig (die Betonung liegt auf wenig ) schlauer, aber so richtig was gefunden habe ich nicht.

Also erstmal muss man zw. wait-free und lock-free unterscheiden. Wait-free gibt es so gut wie gar nicht, weil sie performance-mäßig nicht so der Bringer sind (sollen wohl selbst einfach gelockte Sachen schneller sein) und sie haben einen hohen Speicherverbrauch der wohl linear mit der Anzahl der Threads steigt.
Lock-free hingegen ist ne sehr interessante Sache, denn damit gibt es keine Deadlocks mehr und man kann auch Threads/Prozesse beenden die gerade an der Datenstruktur arbeiten ohne das was passiert.
Performancemäßig sind die (richtig programmiert) auch schneller und verbrauchen sogar weniger Speicher (war an nem Bsp von nem MemoryAllocator) als ne schnelle gelockte Variante.

Falls hier irgendjemand ist der mehr darüber weiß, immer her damit.

542

Lowlevel-Coding / Re:App-/GUI-Server

« am: 28. October 2010, 22:17 »

Ich glaube (nicht wissen) das FlashBurn an ein paar Stellen den Host (auf dem FlashBurn sein OS laufen soll mitsamt seinen Programmen) und den Client (auf dem irgendein OS mit irgendeinem Terminal-Programm läuft) verwechselt hat.

Oder du vergisst das mein OS auf nem PC mit Bildschirm und ohne laufen kann/wird. Ich wollte schon das ich von meinem OS aus mit meinem OS auf einem Headless-System kommuniziere!

Die Frage ist nur wie die Schnittstelle nach unten (zum VGA-Text-Modus-Treiber) aussehen sollte. Wenn die sich an VGA orientiert dann wird sie wahrscheinlich kaum portierbar.

Selbst wenn es sowas wie den Textmodus unter x86 nicht auf anderen Plattformen gibt, dann will ich nen Treiber der auch den Textmodus darstellt (auch wenn das eigentlich grafisch ist) und dieser Treiber soll nur die Zeichen die du ihm gibst, eins nach dem anderen auf dem Bildschirm ausgeben und dann halt noch so Sachen wie CLS und Cursor-Sachen.
Das sollte ziemlich portabel sein.

Die Idee das man dann über TCP auch wie über RS232 kommunizieren kann gefällt mir besonders 

543

Lowlevel-Coding / Re:App-/GUI-Server

« am: 28. October 2010, 13:38 »

Oder du legst einfach 13107 Bytes (64K/5 Terminals) für jedes Terminal im Grafikspeicher fest und schreibst, wenn von stdout Daten kommen in den entsprechenden Bereich im Grafikspeicher (und kümmerst dich um das Scrolling). Damit hast du in jedem Terminal über 2 volle Bildschirme als Scrollback-Buffer und es kostet nichtmal RAM.

Ich behaupte mal was die Portabilität angeht ist meine Variante wesentlich einfacher umzusetzen! Zumal ich so auch die Anzahl der Bildschirmseiten die gebuffert werden dynamisch festlegen kann und auf jeder Plattform funktioniert alles gleich (ich meine damit das auf jeder Plattform die gleiche Anzahl an Terminals genutzt werden kann ohne ein externes Programm wie screen zu nutzen).

Die ganzen Pipes für die einzelnen Terminals kannst du auch mittels AIO verwenden (also ein poll() = WaitForManyPipes() ). Du musst halt nur via Lock dafür sorgen, dass immer nur ein Pipe-Request gleichzeitig in den Grafikspeicher gehen kann und dass du beim Scrollen nicht in fremde Terminalseiten schreibst. AIO verwendet nur einen Thread, das spart das Locking.

AIO habe ich noch nicht und steht auf meiner ToDo-Liste auch ganz weit unten. Busy-Waiting benutzen meine Pipes auch nicht (zumal meine Pipes ja ein wenig anders funktionieren als "normale" Pipes).

544

Lowlevel-Coding / Re:App-/GUI-Server

« am: 27. October 2010, 21:29 »

Um die Sache mal ein wenig zu vereinfachen lassen wir die GUI Lösung jetzt mal außen vor. Denn wir hatten uns ja geeinigt dass das ein Terminalemulator alles macht.

Wenn du auf deinem Rechner eine Terminalemulation möchtest, die mit der seriellen Schnittstelle agiert, dann hat das gefälligst ein Programm zu tun, was die serielle Schnittstelle und ihre Eigenheiten kennt (Baudrate konfigurieren kann, ...), zum Beispiel "minicom", ein Terminal, welches dir Tastatur und Bildschirm mit einem externen Programm verbindet.

Ok, vereinfacht die Sache schonmal weiter.

Der Con-Server stellt dir ein (oder mehrere) Terminals auf der VGA-Grafikkarte im Zusammenspiel mit dem Input-Server zur Verfügung

Mir ist ein neuer Name eingefallen, der besser passt ... TUI-Server (hat nichts mit dem Reiseunternehmen zu tun ).
Denn er emuliert ja nicht nur einfach ein Terminal, sondern viele und kümmert sich auch darum welches gerade im Vordergrund ist. Man kann sagen das es im weitesten Sinne ein WindowManager für den Textmodus ist.

Richtig, das wäre dann - um bei deiner Terminologie zu bleiben - der Seriell-Server.

Zwecks Terminologie, so lange du nicht alles in den Kernel packst kann ich mit Linux-Begriffen leben, aber ich mache nicht aus allem nen Server

In dem Fall würdest du dich beim Device-Server melden und nach einer seriellen Schnittstelle fragen und wirst dann direkt mit dem Treiber kommunizieren.

Solche Sachen in den Con-Server zu integrieren ist unnötig (wird in dem Umfang nur selten benutzt), schwierig umzusetzen und erhöht die Komplexität enorm.

Kann sein das meine Unwissenheit mir jetzt was falsches sagt, aber ich sehe da keine Schwierigkeit und auch keine Komplexität.

Du erstellst einfach für jedes neue virtuelle Terminal nen Buffer mit der Größe 4000bytes*Anzahl der Bildschirmseiten und schreibst einmal dort alles rein und wenn das Terminal im Vordergrund ist, schickst du die Daten noch zusätzlich an den VGA-Textmodustreiber.
Genau das ist auch das was ich meinte das es sich gut parallelisieren lässt. Man hat einfach einen Thread pro virtuellem Terminal im TUI-Server. Denn so eine Pipe fasst ja auch nicht unendlich an Daten.
Kommt ein anderes Terminal in den Vordergrund "kopierst" du einfach den Buffer (die Cursorposition muss natürlich mit einbezogen werden) zum VGA-Treiber und fertig. Einfach und ausreichend schnell.

Die serielle Schnittstelle als Terminal redet nur mit dem dort angeschlossenen Gerät, nicht mit Tastatur/Bildschirm.

Ich habe sowas noch nie gemacht und daher bin ich dabei noch etwas unsicher.

Also läuft das im Prinzip so ab, das ich Stdin an die serielle Schnittstelle weiterleite und was von der seriellen Schnittstelle kommt leite ich an Stdout weiter?
So muss ich auch nichts bei mir (da wo das Terminal läuft mit Bildschirm) auf den Monitor ausgeben, was ich über die Tastatur eingegeben habe, weil das kommt ja eh von der seriellen Schnittstelle zurück und wird dann auf meinem Monitor ausgegeben.

Falls jemand schonmal so eine "Session" gemacht hat und das so läuft wie ich es oben beschrieben habe, merkt man da ein Lag (weil ja erst zum Empfänger gesendet wird und dann kommt das Zeichen wieder zurück und wird erst dann auf dem Bildschirm erscheinen)?

Einen für die gemeinsamen VGA-Textterminals (Con-Server, du hast nur eine VGA-Karte = nur einen Treiber = nur ein Prozess)

Ich hatte ja oben schon was dazu geschrieben, aber so wie du es schreibst wird es schwierig. Erstmal implementiere ich das nicht im VGA-Treiber und wenn du dann nur einen Thread für viele Terminals hast, wird das schwierig. Denn dann müsstest du ja immer der Reihe nach alle Pipes aller virtuellen Terminals (deren Stdout) abfragen ob Daten da sind und mit meiner Thread-Variante wird das wesentlich einfacher und auch sauberer.

545

Lowlevel-Coding / Re:App-/GUI-Server

« am: 27. October 2010, 18:27 »

Ich dachte, dass du am einfachsten für jedes reale Terminal (welches entweder vom VGA-Textmodustreiber oder vom seriellen Treiber oder vom graf. Terminalemulator bereitgestellt wird) einen neuen virtual-Terminal-Serverprozess startest. Jeder dieser Prozesse hat ein eigenes stdin/stdout und kann das somit auch verwalten.

Ich will eigentlich nicht das der serielle Treiber (als Bsp.) nen Terminal bereitstellt, sondern der soll nur Daten empfangen oder senden, nicht mehr.
Das selbe gilt für den VGA-Textmodetreiber. Solange ich mich im Textmodus befinde, soll der nur 16-bit Wörter erhalten die er dann einfach in den Hardwarebuffer kopiert. Dazu muss er noch die Möglichkeit bieten, CLS und ein paar Cursor-Sachen machen zu können, aber die Terminalverwaltung soll er nicht machen.

Die Lösung zwecks des Eingabe/Ausgabe Problems könnte folgendes sein. In jedem virtuellen Terminal läuft irgendein Programm (also auch in dem das über die serielle Schnittstelle kommuniziert). Ich würde jetzt einfach ne neue Pipe für jeweils Stdout/Stderr/Stdin aufmachen und die an den Prozess als Stdout/Stderr/Stdin weiterreichen.
So kann ich einfach die serielle Schnittstelle öffnen und die Daten in die Pipe für Stdin reinschreiben und die Daten die aus der Pipe für Stdout kommen, werden einmal auf dem Bildschirm ausgegeben und einmal an die serielle Schnittstelle geschickt (bzw. umgedreht bin da gerade etwas verwirrt).
Das gleiche mit nem normalen Terminal. So kann ich auch Double-Buffering betreiben und kann die Verwaltung übernehmen (welches Terminal die Eingabe bekommt, also im Vordergrund ist usw.) und muss das nicht in irgendeinem Treiber haben.
Das liese sich auch alles wunderbar parallelisieren (in Threads) und die Ausgabe läuft weiter ohne dass das Terminal im Vordergrund sein muss.

546

Lowlevel-Coding / Re:App-/GUI-Server

« am: 27. October 2010, 17:53 »

Gehst du nicht immer entweder auf ein richtiges Terminal oder auf die serielle Schnittstelle? Du brauchst doch nicht beides gleichzeitig?

Naja, ich dachte halt an die Situation, dass im virtuellen Terminal 1 ne normale Shell läuft und auf dem virtuellen Terminal 2 läuft halt irgendeine Session über die serielle Schnittstelle (wo die Ausgabe von der seriellen Schnittstelle auf dem Bildschirm erscheint und die Eingabe die du im Terminal machst wird halt ans andere Ende der seriellen Verbindung geschickt und auf dem Bildschirm gezeigt).
Genauso sollte es dann auch möglich sein mit einem Headless System (eins ohne Bildschirm oder Ausgabe auf diesem) über ne serielle Schnittstelle zu interagieren (dazu muss ja trotzdem nen Terminal laufen).

Und Svenskas Vorgaben, dass das Textmodusterminal nichts können darf, halte ich auch für Blödsinn.

Ich weiß schon gar nicht mehr was er damit meinte, aber sowas wie Farbe und ANSI-Codes soll es schon können.

547

Lowlevel-Coding / Re:App-/GUI-Server

« am: 27. October 2010, 17:04 »

d.h. er lebt ausschließlich im VGA-RAM (64KB) und unterstützt (max) 6 virtuelle Terminals, je nach gewünschter Größe des Screen-Buffers, außerdem braucht er kein Double Buffering.

Das ist meiner Meinung nach aber nicht wirklich portabel bzw. verlangst du dann ja vom VGA-Treiber (oder sonst was Treiber z.B. seriell) das er es ermöglicht das man mehrere Screenpages hat und auch mal zurück (nach oben) scrollen kann (was ich eigentlich schon gerne drin hätte).

Was mir grad einfällt... wenn du den Terminal-Emulator als Anwendung realisierst, auch für den Textmodus, dann kannst du ihn später auch auf serielle Leitungen oder Telnet-/SSH-Verbindungen ansetzen. Diese sind ja auch "nur" Terminals (bzw. Pseudo-Terminals unter Linux).

Ich dachte mir das dann so, das man dem Programm irgendwie sagen muss welches Gerät er für die Eingabe und welches er für die Ausgabe nutzt.
Da fällt mir gerade auf, das es schwierig wird mit den mehreren virtuellen Terminals das alles in einer Anwendung zu haben. Denn es wäre ja auch net, wenn eins von den virtuellen Terminals die Ein- und Ausgabe über ne serielle Schnittstelle macht, aber da ja schon die File-Handles 0-2 vergeben sind wird das nicht so einfach.
Hast du da vllt noch eine Idee?

548

Lowlevel-Coding / Re:App-/GUI-Server

« am: 27. October 2010, 14:46 »

Ein Terminalemulator ist ein GUI-Programm, welches in seinem Fenster ein Terminal emuliert. Nicht weniger.

Dann hätten wir das also schonmal geklärt!

Da ich denke dich jetzt endlich verstanden zu haben, werd ich es einfach so machen, das ich nen "Terminal-Emulator" für den Textmodus schreibe (der ANSI kann) und dann viel später einen für den GUI-Server und damit fällt der Con-Server komplett weg.

Mein Textmodus-Terminal muss dann halt trotzdem ein wenig mehr können, sprich Double-Buffering und mehrere virtuelle Terminals.

Jetzt sollte ich (bzw. vorallem svenska ) doch alles schön vereinfacht haben und ihr habt dem nichts mehr hinzuzufügen, oder?

Was auf keinen Fall geht, ist dass ein Programm nen Treiber enthällt, das wiederspricht absolut dem was ich mit meinem Treibermanagement vorhabe!

549

Lowlevel-Coding / Re:App-/GUI-Server

« am: 27. October 2010, 10:35 »

Genau. Aber für den Con-Server bleibt dann keine Aufgabe mehr, der müsste ja nur noch stdin/out an den Terminalemulator durchreichen. Das geht auch direkter.

Ich will mir halt "ersparen" 2mal den selben Code zu schreiben. Deswegen soll der Terminal-Emulator ja auch nur so "wenig" können.
Der Con-Server hätte halt eine allgmeine "Sprache" in die übersetzt werden muss und der Con-Server verwaltet die ganzen Konsolen, sprich er weiß welche gerade im Vordergrund ist und leitet die Daten vom Intput-Server entsprechend weiter und er macht das ganze Double-Buffering.

Wie ich es mir am Anfang vorgestellt hatte, und wie ich denke, dass es Sinn ergibt, ist, dass der Con-Server sozusagen ein Textmodus-Terminalemulator mit eingebautem Textmodus-Grafiktreiber ist.

Den Terminal-Emulator will ich halt da raus halten und das der den Textmodus-Grafiktreiber mit integriert hat wird unter meinem OS nicht funktionieren.

Von den GUI-Nachrichten sollte die Anwendung überhaupt nichts mitbekommen. Der Terminalemulator soll daraus irgendwas vernünftiges machen, z.B. in Escapesequenzen umwandeln oder Signale schicken.

Die Anwendung bekommt davon auch nichts mit, es ging mir alleine um den Terminal-Emulator, dass dieser wissen muss ob er gerade im Textmodus läuft oder im Grafikmodus und läuft er im Grafikmodus müsste er sich um die ganzen Fenster-Msgs kümmern.

Das ist der Terminalemulator, ein ganz normales GUI-Programm.

Und genau das will ich halt so nicht machen. Für mich soll der Terminal-Emulator immer nur eine Art Übersetzer sein, nicht mehr und nicht weniger.

Ich sehe auch nicht, in welche Sprache dieser "Terminalemulator" übersetzen sollte. Auf der einen Seite vt100, klar, aber auf der anderen? Der Ansatz kommt mir im Moment wenig sinnvoll vor.

Der Terminal-Emulator soll von z.B. vt100 in eine allgemeine vom Con-Server unterstützte "Sprache" übersetzen. So halte ich mir halt die Möglichkeit offen noch andere Sachen als vt100 zu unterstützen ohne das ich das alles in ein Programm packen müsste. Ob das sinnvoll ist sei erstmal dahin gestellt.

Wie gesagt, Con-Server für die GUI ergibt in meinen Augen keinen Sinn. Der Con-Server ist das, was im Textmodus das Terminal implementiert, in der GUI brauchst du sowas nicht.

Ok, um es anders zu sagen. Ihr habt doch bei tyndur auch nen Terminal-Emulator (vterm), oder? Wie soll das dann irgendwann mal mit einer GUI laufen? Wollt ihr dann noch nen Terminal-Emulator für die GUI schreiben oder erweitert ihr euren bisherigen?

Worauf ich hinaus will, entweder man muss mehrere Terminal-Emulatoren schreiben, einen für den Textmodus und einen für den GUI-Modus oder man erweitert sein vorhanden Textmodus mit dem Code für den Grafikmodus.

Letzteres will ich nicht, da ich im Moment so plane, das man mein OS auch einfach nur als Konsolenvariante starten kann (so wie Linux ohne GUI-Krams). Ersteres will ich auch vermeiden, weil mal davon ausgehend, dass ich wirklich (ob das je so sein wird, ist mir erstmal egal) mehrere Terminal-Emulatoren habe, dann müsste ich ja für jeden 2 Varianten schreiben und beide Varianten hätten einen Teil des gleichen Codes (der "Übersetzer") und alle Terminal-Emulatoren hätten auch den gleichen Code (die ganze Fenster-Msgs Geschichte) und ich sehe es da halt so, einfach den gemeinsamen Teil von beiden Varianten in eine Stecken und den gemeinsamen Teil aller Emulatoren in etwas anderes auslagern (Con-Server).

Ich hoffe du kannst jetzt meine Motivation für dieses "Design" nachvollziehen.

550

Lowlevel-Coding / Re:App-/GUI-Server

« am: 27. October 2010, 09:51 »

Das ist Aufgabe des GUI-Servers, denn der hat die Hoheit über den Grafiktreiber und je nach Grafikhardware lässt sich das Zeichenzeichnen hardwareseitig beschleunigen.

Da drücke ich mich wahrscheinlich falsch aus. Ich meine nicht das der Con-Server die Fenster zeichnet, sondern dass er sich um die ganzen Sachen kümmert die ein GUI-App so machen muss. Sprich es kommt ne Msg vom GUI-Server das mit der Maus in das Fenster geklickt wurde, diese Msg soll dann vom Con-Server bearbeitet werden usw. (was es da halt noch so alles an Msgs geben kann z.B. Fenstergröße hat sich geändert).

Diese ganze GUI-App Geschichte würde ich halt am liebsten von einem Terminal-Emulator fern halten, damit der im Textmodus und im Grafikmodus benutzt werden kann ohne das er sich darum selber kümmern muss.

Ich stelle mir den Terminal-Emulator so vor, das der Stdout zum Con-Server (oder GUI-Server) schickt und als Stdin bekommt er Daten von der Shell/dem Textmodus-App. Das einzige was er (der Emulator) machen soll ist die Escape-Sequenzen zu übersetzen, mehr nicht und dann kann er nämlich einfach als Vermittler im Text- und im Grafikmodus eingesetzt werden.

Solch eine Flexibilität wäre halt net bzw. Wiederverwendbarkeit.

Außerdem kämpfen dann nicht zwei Server um begrenzte Ressourcen (Con-/GUI-Server kämpfen sonst um Tastatur und Bildschirm) - es ist nur einer zuständig.

Deswegen ja die Anmeldesequenz des GUI-Servers. Der meldet sich beim Input-Server, dass er jetzt zuständig ist und nicht mehr der Con-Server und dem Con-Server sagt er das auch nochmal (bzw. (siehst du das dann weiter unten) "ersetzt" er den Con-Server für den Textmodus mit dem Con-Server für den Grafikmodus).

Wenn du ein Textmodus-Programm ohne stdin/stdout/stderr startest, hat es halt keine Möglichkeit, damit zu arbeiten und gut. Für Hintergrundprogramme ist das durchaus gängige Praxis (Eingaben via Konfigdateien und Ausgaben via System-Log-Mechanismen).

Ich weiß nicht wie das unter Linux läuft, aber unter Windows funktioniert es das man einfach nen Doppel-Klick auf nen Textmodus-App macht und dann öffnet sich ne Textkonsole (im Hintergrund läuft dann unter W7 conhost.exe, glaub ich).

Deswegen überlege ich halt wie ich das am besten Umsetze, da so eine Funktionalität schon nicht schlecht wäre, ich das aber auch gerne schon vorher geplant haben will, damit ich nachher nicht nen Rewrite machen muss.

Wenn ich deine Variante umsetze, dann muss ich im Grafikmodus immer erst nen Terminal-Emulator öffnen damit ich ein Textmodus-App ausführen kann (und auch was sehe) und dieser muss sich bewusst sein das er gerade im Grafikmodus läuft und das er dann die ganzen Fenster-Msgs handlen muss.

(Was mir in dem Zusammenhang noch einfällt, hat man unter Linux eigentlich ne Umgebungsvariable wo drinsteht welche Shell benutzt werden soll? Weil die müsste ja immer vom Terminal-Emulator mitgestartet werden.)

In dem Moment, wo du den GUI-Server startest, sollte dieser inklusive aller enthaltenen Anwendungen beendet werden, da der GUI-Server einen eigenen Grafiktreiber lädt.

Das hätte ich dann halt so lösen wollen, das der Con-Server dann (deswegen soll sich der GUI-Server beim Con-Server anmelden) für jede laufende Terminal-Emulation ein Konsolenfenster aufmacht und die Programme da drin dann einfach weiterlaufen als wäre nichts gewesen (deswegen auch Doublebuffering in Software).

Du könntest natürlich ein Dummy-stdout bereitstellen und wenn da Daten auflaufen automatisch einen Terminalemulator starten und dem das stdout der Anwendung übergeben. Das wäre praktisch.

Genau sowas wollte ich machen.

Also nochmal (nach dem ich hoffentlich geklärt habe was ich mit Fensterverwaltung meine).

Mein Problem ist einfach das ich den Con-Server gerne so gestalten würde, dass er keinen Code hat der was mit dem Grafischenmodus zu tun hat, aber ich will auch nicht das der GUI-Server sich um alles was mit nem Konsolenfenster zutun hat kümmern muss.

Der GUI-Server soll einfach nur Fenster verwalten und er soll zu jedem Fenster (ob nun Konsolenfenster oder "normales" Fenster) einen "Ansprechpartner" haben und genau den habe ich halt für Konsolen-Apps noch nicht gefunden.
Der Terminal-Emulator (wie oben geschrieben) soll einfach nur die Escape-Sequenzen übersetzen mehr nicht! Stell dir den Terminal-Emulator wie nen Druckertreiber vor, der keine "Ausgabe" (in dem Sinne das er nen Fenster oder sowas bräuchte) macht, sondern einfach nur von einer Sprache in eine andere Übersetzt. Das hätte auch den Vorteil, das ich dann einfach nur nen Doppel-Klick auf nen Terminal-Emulator machen muss (der so auch im Textmodus funktioniert) und der halt als Stdout ne Leitung zum Con-Server bekommt und ein neues Fenster aufgeht bzw. im Textmodus, würde dann halt ne neue virtuelle Konsole "aufgehen".

Das ganze würde jetzt darauf hinauslaufen, das ich einen Con-Server für den Textmodus habe (wo ich mir auch noch nicht sicher bin, wie dieser mit dem VGA-Treiber/Textmodus-Treiber kommuniziert) und einen Con-Server für den Grafikmodus habe, welcher dann halt dem GUI-Server sagt, dass er nen neues Fenster braucht und das sich dieser Con-Server (für den Grafikmodus) dann um die ganzen Msgs, die da so vom GUI-Server kommen, kümmert.

Ich könnte beim Terminal-Emulator sogar noch ums Vererben drumrum kommen, indem ich sage, der muss sich grundsätzlich erstmal beim gerade laufenden Con-Server melden und sich seine Stdout/Stdin holen.

551

Lowlevel-Coding / Re:App-/GUI-Server

« am: 26. October 2010, 21:27 »

Und es ist ein Zeichen, dass der Textmodus langsam überholt ist. Du findest so gut wie kein Linux, auf dem keine grafische Oberfläche installiert ist, sofern Tastatur und Bildschirm angeschlossen sind (d.h. reine Server mal ausgenommen).

Bitte nicht vergessen, das wir hier über ein Hobby-OS reden, das irgendwann mal auch nen GUI haben möchte und auf allem laufen soll ab P75 (mit ein paar Ausnahmen).
Von daher ist der Textmodus bzw. max grafischer Textmodus fürs erste das höchste der Gefühle (auch wenn man bei einem OS am liebsten mit der GUI anfangen würde ).

Jein, wenn dein Con-Server und dein GUI-Server gleichzeitig laufen, muss klar erkennbar sein, welcher jetzt gerade aktiv ist. Nur an den darf weitergeleitet werden. Ansonsten: exakt.

Ok, sprich der GUI-Server meldet sich nicht nur beim Con-Server an, sondern auch beim Input-Server und dieser schickt alle Daten an den GUI-Server, welcher die Daten entsprechend weiterleitet.

Der Con-Server sollte keine Fenster öffnen, sondern der GUI-Server. Der Con-Server könnte höchstens ein neues virtuelles Terminal öffnen, aber das fände ich etwas übertrieben. Textanwendungen haben ihr Terminal ja bereits.

Das ist jetzt der Punkt wo ich schwanke. Auf der einen Seite wäre es schön, wenn ich sage das der Con-Server sich um die komplette Fensterverwaltung kümmert (damit meine ich nicht das er das Fenster "erstellen" soll, sondern er "zeichnet" sozusagen die Zeichen in das Fenster). Auf der anderen Seite, könnte ich den Con-Server komplett beenden wenn der GUI-Server erstmal läuft. Nur wird es dann auch schwieriger andere Dinge als Zeichen auszugeben (oder könnte man Funktionen wie CLS oder Cursor-Sachen auch als Escape-Sequenzen implementieren?). Auch würde es den Con-Server schlanker machen. Von daher wäre diese Variante eigentlich zu favorisieren!

Ähm... der Con-Server hat sich aus der grafischen Umgebung rauszuhalten. Da gelten andere Konzepte. Der GUI-Server wiederum sollte keine Terminalemulation bieten, das ist Aufgabe einer Terminalemulator-Anwendung, die für den GUI-Server ein Fenster mit Fokus ist, für die Anwendung darunter ein (Pseudo-)Terminal.

Jetzt wirds wieder unverständlich. Das Problem welches ich habe ist, das ich zwischen einem normalen Fenster und einem Konsolenfenster schon unterscheide und Vereinfachungen vornehmen würde. Deswegen ja die ganze Geschichte mit dem Con-Server zusammen.
Auch würde ich es nicht wollen, das die Terminal-Emulations-Anwendung zwischen TUI und GUI unterscheiden muss. Am liebsten würde ich das so transparent wie möglich halten. Also entweder übernimmt der Con-Server die Fenster-Sachen oder halt der GUI-Server.

Eine andere Frage wäre, wie läuft das denn unter Linux, kann man da auf ein Programm welches ncurses benutzt einfach nen Doppel-Klick machen und der richtige Terminal-Emulator wird aufgerufen oder klappt es nur so, das man nen Terminal-Emulator öffnet und dann erst das Programm starten kann?

Ist der erste Fall richtig, dann müsste ich ja die Terminal-Emulation schon in den Con-Server und/oder den GUI-Server packen, weil ich ja nicht ohne weiteres jedes Programm mit einem bestimmen Terminal-Emulator verbinden kann.

Oder verstehe ich da jetzt wieder was total falsch?

außerdem gibt es zu jedem Terminal eine Datei (wird angezeigt von "tty", sowas wie /dev/tty2 [terminal] oder /dev/pts/1 [pseudoterminal] oder /dev/tts/1 [serielle leitung]), auf die man dann Terminal-ioctls anwenden kann.

Blöd gefragt, was kann man denn alles mit den Terminal-ioctls machen? Oder anders wofür ist das gut (ich will ja eigentlich nicht das Konzept "alles ist eine Datei" umsetzen)?

552

Lowlevel-Coding / Re:App-/GUI-Server

« am: 26. October 2010, 16:30 »

Naja, unter Linux definiert dein Terminal $TERM und ncurses guckt dann in der Konfiguration nach, wie es mit diesem $TERM ("linux", "xterm", "vt220", ...) umzugehen hat, um möglichst effiziente Ergebnisse zu erzielen.

Jetzt hast du mich komplett verwirrt

Kann man unter Terminal nun eine Shell oder meinen Con-Server verstehen? Ich vermute mal eher letzteres.

Ein primitiver Grafiktreiber ist nicht wesentlich schwieriger (von den Textzeichen mal abgesehen) als ein guter Textmodus-Treiber, dafür aber wesentlich flexibler.

Ich gehe mal davon aus, das selbst Linux verdammt lange einfach nur die Ausgabe im "Textmodus" gemacht hat, weil es einfacher und schneller ist. Das ein guter Textmodus-Treiber flexibler ist, ist logisch und Portabilität steht im Moment ganz ganz weit unten auf meiner ToDo-Liste

Nö. Du möchtest auch systemweite Kürzel (z.B. SysRq oder virtuelles-terminal-wechseln) implementieren können, die direkt die grafische Oberfläche (den GUI-Server) betreffen. Also hat der Input-Layer an das virtuelle Terminal und damit an die gesamte grafische Oberfläche weiterzuleiten. Die darf dann selbsttätig die Inputs weiterverarbeiten. (Joystick-Eingaben gehen u.U. an andere Fenster als das mit dem Fokus, oder deine Sekundärtastatur ist nur für eine bestimmte XTerm nutzbar. Flexibilität.)

Wenn ich dich richtig verstehe, würdest du also die Eingabe an den Con-Server und den GUI-Server (sofern dieser läuft) weiterleiten und diese sehen dann was sie damit machen, um eventuell die Daten an eine entsprechende App weiterzuleiten?

Im Textmodus solltest du dich aber auf den Hardwarebuffer beschränken, der ist schneller; im Grafikmodus kannst du dich auf z.B. 4 Seiten festlegen, sofern genug Grafikspeicher verfügbar ist.

Also ganz ehrlich, wieso sollte ich mich auf den Hardwarebuffer beschränken, das wäre ja quatsch (im Textmodus)? Wir reden hier davon 80*25*2= 4000bytes von einem Buffer irgendwo im RAM in den Hardwarebuffer zu kopieren und das sollte selbst auf nem P75 (kleinster unterstützter Pentium von mir) so schnell sein, das es nicht spürbar ist!
Was den Grafikspeicher angeht das selbe. Denn du kannst ja nicht sagen, tut mir leid noch eine Anwendung kann nicht gestartet werden, weil nicht genügend Grafikspeicher vorhanden ist, aber RAM habe ich noch verdammt viel frei!

In der grafischen Oberfläche musst du wissen, ob dein Programm ein Textmodusprogramm ist (Windows) und dann ein Konsolenfenster öffnen oder (Linux) du startest das Programm ohne stdin/stdout/stderr, weil es die unter der grafischen Oberfläche ja nicht gibt. Alternativ überwachst du mit einem Dummy-stdout und wenn es benutzt wird, dann startest du das Konsolenfenster bei Bedarf...

So ähnlich dachte ich mir das (letzteres). Nämlich das man immer Stdout/Stderr/Stdin mir gültigen Pipes versieht und der Con-Server macht erst nen neues Konsolenfenster auf, wenn auch was auf Stdout/Stderr ausgegeben wird (wird unter Windows auch gemacht, möchte ich meinen).

An das Vererben habe ich allerdings in diesem Fall wirklich nicht gedacht. Nur finde ich es einfacher wenn sich der Con-Server dann im grafischen Modus um die ganze Fenstergeschichte kümmert, als wenn ich das dann auch noch im GUI-Server machen müsste bzw. so könnte man dann auch andere Terminal-Emulationen ermöglichen ohne das ich das im GUI-Server habe.

Abstrahiere es weg und baue einen VTerm-Server, der sich um den Bildschirm kümmert und je nach Wunsch des Nutzers an einen GUI- oder einen TUI-Server weiterleitet.

Auf der einen Seite wäre es ein Server, aber ich würde es jetzt mal Programm nennen und die Idee gefällt mir, damit habe ich wieder alles aus dem Con-Server raus und in einem externen Programm drin. Somit könnte ich wieder mehrere Terminal-Emulationen zur Verfügung stellen ohne das alles an einem zentralen Ort sein müsste.

Ich weiß nicht ob es zuviel verlangt wäre, wenn ihr mir helfen könntet nen Interface bzw. die Funktionen die man benötigt (für den Con-Server, der allgemein bleiben muss um die Terminal-Emulationen zu ermöglichen) zu entwerfen?!

553

Lowlevel-Coding / Re:App-/GUI-Server

« am: 26. October 2010, 15:51 »

Hä, ich verstehe nicht was Du meinst.

Ok, mein OS ist fertig gestartet und man findet sich in/auf einer Shell wieder. Jetzt will man aber noch eine Shell/"Fenster" öffnen. Wie man das lösen soll, das weiß ich halt noch nicht.
Ob man z.B. ne Tastenkombination nimmt (z.B. STRG+N) oder was mir lieber wäre, das man nen Programm aufruft und dem vllt die neue Shell als Parameter übergibt (so dass man auch verschiedene Shells starten kann).

554

Lowlevel-Coding / Re:App-/GUI-Server

« am: 26. October 2010, 15:32 »

Also immer schön hierarchisch denken und das erben nicht vergessen.

Was ich meine ist, ob man einfach ne Tastenkombination dafür nutzt oder ob man die Shell manuel starten muss (z.B. "/bin/bash").
Unter Windows z.B. bringt es dir gar nichts wenn du cmd.exe in der Aufgabeaufforderung aufrufst. Denn es wird kein neues Fenster erzeugt und unter Mingw bash/sh das gleiche.

555

Lowlevel-Coding / Re:App-/GUI-Server

« am: 26. October 2010, 14:33 »

Es sei denn, du willst für JEDEN interaktiven Prozess immer die Hintergrundshell im Speicher haben...

Sehr gutes Argument. Natürlich nicht.

Du musst dann nur ncurses o.ä. erklären, wie man sie benutzt, dann sind alle ncurses-Applikationen sofort lauffähig.

ncurses ist im Endeffekt genau sowas was ich gesucht habe, nur auf die schnelle konnte ich nichts finden wie das funktioniert. Ich meine damit woher weiß ncurses was es wie benutzen kann? Oder anders wenn ich bestimmte Excape-Sequenzen habe, dachte ich immer das hängt mit der benutzten Shell (deswegen mein Gedanke alles über die Shell machen zu lassen) zusammen ob da was sinnvolles am Monitor erscheint oder nicht.

Beachte übrigens auch, dass du nicht unbegrenzt viel Arbeit vom Kernel auf die Shell verlagern kannst oder auch solltest

Mit dem Kernel hat das alles rein gar nichts zu tun, aber du meinst bestimmt meinen Con-Server?!

Was passiert, wenn dein GUI-Server ein Textprogramm oder ein Con-Server ein Grafikprogramm ausführen soll?

Ich vermute mal das ist wieder zu Linux-haft gedacht

Weder GUI- noch Con-Server führen ein Programm aus. Was ich meine ist, das ein Programm sich nicht darum kümmern brauchen soll, ob gerade der GUI-Server läuft oder nicht.
Ist es ein grafisches App "verbindet" es sich mit dem GUI-Server (oder gibt ne Fehlermeldung aus, das kein GUI-Server läuft) und ist es ein TUI-App verbindet es sich mit dem Con-Server, bzw. wird halt einfach alles über Stdout gemacht. Ich möchte aber nicht, das ein App sich darum kümmern muss, ob sie (sozusagen) die Ausgabe über den Con-Server oder über den GUI-Server machen soll (wenn es nur Stdout betrifft).

Randbemerkung: Textmodi gibt es nur bei (prä-)VGA und sind daher ohnehin hochgradig an die PC-Plattform gebunden / unportabel; außerdem sind Textmodi nur begrenzt UTF8-fähig und ein Relikt aus früheren Zeiten. Musst du das unterstützen? Ich denke, ich würde mir die Arbeit nicht machen wollen.

Anders gefragt, warum soll ich mir die Arbeit machen nen Grafiktreiber zu entwickeln, wenn ich erstmal nur Text habe, wenn das alles auch ohne Grafiktreiber läuft.
Mit Textmodus meine ich eigentlich das du nen Buffer hast wo du deine Zeichen und die Flags (Farben usw.) reinschreibst und das erscheint dann auf dem Bildschirm.
Gibt es das nicht auch auf anderen Plattformen?

Die Eingaben solltest du bevorzugt über einen Eingabe-Server/-Multiplexer machen, denn du kannst ja auch Eingabegeräte jenseits der Tastatur anschließen (Joystick, Maus, Touchscreen, USB-Zweittastatur). Die sollten sich für das System nicht voneinander und von Tastaturen unterscheiden. Wenn du da eine gute Abstraktion einbaust, kannst du außerdem quasi-kostenlos eine Bildschirmtastatur implementieren, die dann nur in die Input-Queue injiziert.

Genau so habe ich mir das vorgestellt. Allerdings hatte ich vorhin irgendwie nicht daran gedacht, wie man halt die Daten vom Input-Server zum richtigen Programm bekommt und daher wollte ich das über den entsprechenden Server leiten (Con oder GUI), weil der ja weiß welches "Fenster" gerade den Fokus hat.

Es wäre aber auch möglich einfach jedes Mal dem Input-Server mitzuteilen welches App gerade den Fokus hat, so spart man sich das umleiten.

Der Screenbuffer im Textmodus ist üblicherweise (Grafikspeicher / num_virt_Terminals), wobei der Grafikspeicher bei VGA 64KB groß ist (bei MDA 4KB). Du kannst also höchstens 8 virtuelle Terminals haben, dann aber ohne HW-Scrolling und Screenbuffer.

Ich denke mal du hast mich falsch verstanden. Ich meine den Softwarebuffer, sprich egal wie groß der Hardwarebuffer ist (z.B. nur eine Bildschirmseite) buffere ich das ja in Software nochmal. So dass ich dann immer, keine Ahnung vielleicht 4 Seiten habe?

Was die Anzahl der virtuellen Terminals betrifft, da wollte ich mir was einfallen lassen, dass man immer wieder ne neue/zusätzliche Shell starten kann (ich rede jetzt mal nur vom Textmodus) und dann zwischen diesen hin und her "zappen" kann.
Ich weiß nur noch nicht, wie ich das mit dem eine neue Shell starten machen soll.

556

Lowlevel-Coding / Re:SMP und die damit verbundenen Probleme

« am: 26. October 2010, 12:54 »

dürften da eventuell noch ne Menge Deadlocks, mit "Circular Wait", lauern.

So neuer Thread ist auf, dann such mal danach. Ich konnte keine mehr finden 

557

Lowlevel-Coding / Mein VMM Design

« am: 26. October 2010, 12:50 »

So da es ja Stimmen gibt die mein VMM Design als kaputt oder fehlerhaft bezeichnen wollen wir dem mal auf den Grund gehen.

Im Endeffekt geht es ja "nur" darum wie und in welcher Reihenfolge ich locke.

Ich werde das Design erstmal nur grob umreißen, da der Code inzwischen fast 2000 Zeilen groß ist (ohne Kommentare).

Wichtigste Datenstruktur ist ein "struct vmmAddrSpace_t". Darin sind 2 AVL-Bäume mit freien virtuellen Bereichen, einmal nach Adresse sortiert und einmal nach der Größe, ansonsten zeigen die Nodes in beiden Bäumen auf die selbe Datenstruktur.
Dann sind noch 2 Locks mit dabei, einmal um die "Zonen" (also im Endeffekt die beiden Bäume) zu schützen und einmal um die PagingTables des Prozesses zu schützen.

Interessant ist noch, das der KernelSpace seinen eigenen AdressSpace hat.

An Funktionen wird nach außen hin folgendes bereitgestellt:

• vmmAllocMemory(uint32t pages, uint32t flags)
• vmmDeallocMemory(void *base, uint32t pages)
• vmmAllocRange(uint32t pages)
• vmmDeallocRange(void *base, uint32t pages)
• vmmMap(void *virt, void *phys, uint32t count, uint32t flags)
• vmmUnmap(void *virt, uint32t count, uint32t flags

vmmAllocMemory macht nichts anderes als eine Zone/Range zu allokieren (im Endeffekt könnte man sagen das vmmAllocRange aufgerufen wird) und in diese Zone dann Pages zu mappen (Aufruf von vmmMap).
Locks werden nicht direkt genutzt, sondern nur durch das Aufrufen von anderen Funktionen (die noch kommen). Einzige Ausnahme ist wenn ein Fehler auftritt und die bisherige Aktion rückgängig gemacht werden muss, aber da ist mir aufgefallen, dass das auch durch einen Aufruf von vmmDeallocMemory passieren kann.

vmmDeallocMemory unmappt erstmal alle Pages (Aufruf von vmmUnmap), holt sich dann den PageTableLock um die eventuell vorhandenen Pages freizugeben. Danach wird der Lock wieder freigegeben.
Zum Abschluss wird dann die Zone freigegeben (Aufruf von vmmDeallocRange).

vmmAllocRange holt sich den Lock für die Bäume. Dann wird halt nach einer Range gesucht und wird eine gefunden, wird die Node unter Umständen (Node entspricht der benötigten Range) aus dem Baum gelöscht und der Speicher der Node wird freigegeben.
Genau hier lag ein Problem meines Designs, wenn ich nämlich den SlabAllocator aufrufe, während ich den Lock für den KernelSpace habe (was ja passieren kann, wenn eine Range im KernelSpace allokiert werden soll), kann es passieren das es zu einem Deadlock kommt. Denn der SlabAllocator wiederrum könnte ja Speicherfreigeben wollen, aber da der Lock für die Bäume schon belegt ist, kann das nicht funktionieren -> DeadLock.

vmmDeallocRange holt sich den Lock für die Bäume. Dann wird geguckt ob die freizugebende Range mit einer oder zwei vorhanden Ranges zusammengefasst werden kann (dies kann wieder zu mehreren NodeAlloc´s und NodeDealloc´s führen).
Hier war mal genau das selbe Problem wie bei vmmAllocRange, nämlich das der VMM Speicher vom VMM braucht um seine Aufgabe zu erfüllen (klingt lustig war es aber nicht ).

vmmMap holt sich den Lock für die PagingTables und versucht halt die Pages zu mappen, das gleiche macht vmmUnmap, nur das es die Pages unmappt.
Beide rufen noch eine Funktion auf, die sich darum kümmert wie oft jede physikalische Page gemappt ist. Hierfür wird ein Lock pro Page verwendet und dort kann kein Deadlock auftreten, da kein anderes Lock benötigt wird (es wird das Lock geholt, nen Counter inkrementiert/dekrementiert) und das wars schon.

So viele Locks sind es gar nicht, die meinen VMM ausmachen (genau 2 bzw. 3).

Problem war halt mal, das ich für das Allokieren der VMM Datenstrukturen meinen allgemeinen SlabAllocator benutzt habe und der wiederrum braucht den VMM um arbeiten zu können was ja nicht funktionieren kann.

Gelöst habe ich es dadurch, das ich mir extra das Prinzip des SlabAllocators zu nutze gemacht habe und in einem festgelegten Bereich (steht schon zur Compilezeit fest) nur noch Pages gemappt oder geunmappt werden müssen.
Diese Funktion (vmmSlabAllocNode/vmmSlabAllocZone usw.) holt sich nen Lock um ein Element aus dem Cache (wo viele oder auch gar kein Objekt drin ist) holen zu können.
Ist der Cache leer, muss eine neue Page gemappt werden (Aufruf von vmmMap), dafür wird kein neuer Lock benötigt, da eh immer nur einer auf diesen Cache zugreifen kann.

So ich weiß ganz schön viel, aber jetzt dürft ihr mein Konzept niedermachen und könnt Kritik direkt am Konzept (oder zur Not am Code) bringen!

558

Lowlevel-Coding / Re:SMP und die damit verbundenen Probleme

« am: 26. October 2010, 12:16 »

Ich hab geschrieben das es bei vielen Locks sicher auch mal Notwendig ist mehrere zu haben aber ich hab nicht geschrieben das es unmöglich (oder schwierig) ist diese in geordneter Reihenfolge zu holen.

Und genau das mit der Reihenfolge hatten wir doch schon, läuft nach dem LIFO Prinzip. Das andere was du noch meinst ist das Problem das mehrere Pfade zu dem gleichen Lock führen und wie taljeth schon geschrieben hat, wenn du alle Locks immer nur auf einem Pfad holen darfst, brauchst du die ganzen Locks nichts!
Die Locks sind dazu da kleine und möglichst kurze kritische Bereiche, die von mehreren Threads genutzt werden können (und genau das ist der Punkt!), zu schützen.

Solange die Wege zu den einzelnen Locks keine Deadlocks produzieren sehe ich da kein Problem.

Wieso siehst du dort mit einmal kein Problem? Ist doch das gleiche Prinzip, das mehrere Pfade zu einem Lock führen.

559

Lowlevel-Coding / Re:SMP und die damit verbundenen Probleme

« am: 26. October 2010, 10:46 »

Ich würde schon sagen das Dein Design schlecht oder zumindest fehlerhaft ist/war.

Ich kann mit Kritik leben, dann aber bitte auch konstruktiv!

Ich denke dafür wäre aber mal wieder ein neuer Thread nötig, aber nur wenn interesse darin besteht mal ein VMM Design zu diskutieren!?

Das es überhaupt 2 verschieden Pfade gibt um an Lock 2 zu kommen, einmal mit Lock 1 und einmal ohne, das ist Dein Problem!

Lässt sich wie du schon weiter oben mal geschrieben hattest, leider nicht (oder nicht so einfach??) vermeiden.

Ein ähnlicher Fall wäre, dass 2 Prozesse ne Page gemappt haben und dafür haben sie unterschiedliche Locks (weil 2 unterschiedliche Adressräume) und dann wollen beide den Lock um die IPI-Nachricht zu senden. Also ist es gar nicht so ungewöhnlich auf 2 Wegen an ein und die selbe Lock zu kommen (das ist woanders auch noch so)!
Ein weiteres Bsp. wäre, dass man nen Lock für irgendeine Datenstruktur hat und dann neuen Speicher braucht und ne Page mappt, dann hast du einmal den Lock für die jeweilige Datenstruktur und einmal willst du den gleichen Lock für den Adressraum haben.

560

Lowlevel-Coding / Re:App-/GUI-Server

« am: 26. October 2010, 10:20 »

Ich habe mir nochmal ein paar Gedanken gemacht und werde wahrscheinlich (wenn ihr mich nicht vom Gegenteil überzeugen könnt ) nen Con-Server (oder auch Console-Server) und nen GUI-Server haben.

Ich werde, aber nicht vt100 und solche Sachen im Con-Server implementieren, sondern das muss die Shell machen (ist das unter POSIX nicht auch so?). Ich muss mir dann "nur" Gedanken machen, was ich alles zur Verfügung stellen will (Farbe setzen, Position setzen usw.).

Ich habe mir das dann so vorgestellt, das die Shell (egal welche) immer ne Pipe created und diese als Stdout für den Prozess "weitergibt". Der Prozess kann dann halt die Eigenheiten der Shell nutzen (z.B. ne vt100 Emulation) und die Shell "übersetzt" das ganze dann in "Aufrufe" für den Con-Server. So ist es möglich das ich mich weder um die Emulation (vt100) kümmern muss, noch das ich mich auf eine festlegen müsste.

Desweiter dachte ich dann daran, dass der GUI-Server sich beim Con-Server anmeldet und sagt "jetzt wird alles grafisch dargestellt" und der Con-Server kümmert sich dann um die ganze Fenster-Geschichte. So merkt das TUI-App gar nicht wo es gerade läuft, ob Text- oder Grafikmodus.

Das einzige was ich mir noch nicht überlegt habe, wie ich das dann mit der Eingabe mache, ob ich die auch über den Con-Server laufen lassen (wäre wahrscheinlich einfacher), weil sich ja im Grafikmodus auch ein wenig ändert. Da laufen ja nicht mehr nur Shell-Prozesse wo sich der Con-Server darum kümmert wer gerade im Vordergrund/Aktiv ist.

Wie groß sollte man eigentlich den Screenbuffer bei der Konsole wählen oder wie groß ist der allgemein?