Sourcecode Fortschritt

Erhard Henkes

Rev. 144:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=144

ehci.h/c: initEHCIHostController() TEST-Version (erste Gehversuche )

pci.c, Zeilen 187/188:

analyzeEHCI(bar);
initEHCIHostController();

siehe EHCI Spec Rev. 1.0, Kap. 4 "Operational Model"

Ideal: Sun VB oder reale Hardware mit EHCI USB und Netzwerkkarte 8139

(Anm:: rev. 141-143 war fehlerhaft bezüglich rtl8139.c)

Erhard Henkes

Rev. 145:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=145

- Korrektur in RTL8139.c (reset abwarten)
- TTT 0.4 von MrX eingespielt (Sehr schön gemacht! Macht aber Probleme, wenn auf echter Hardware eine RTL8139 vorhanden ist und diese Interrupts und Prints sendet)

Erhard Henkes schrieb:

Rev. 145:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=145

Jede Quellcodedatei die ich bisher von euch gesehen habe (diese z.B.) sieht so furchtbar unvollständig aus. ihr arbeitet wohl an 100 Baustellen gleichzeitig.

Mr X

Es gibt derzeit auch viele Baustellen... Vlt. hast Du konkrete Vorschläge, wo man was verbessern könnte?

Mr X schrieb:

Es gibt derzeit auch viele Baustellen... Vlt. hast Du konkrete Vorschläge, wo man was verbessern könnte?

Mir fällt z.B. auf, dass der Netzwerktreiber keine Sendefunktion hat, dass er direkt TCP aufruft, dass TCP nur eine Empfangsfunktion hat, die noch nicht mal TCP kann. dass TCP irgendwie auch ARP teilweise behandelt, dass alles mit printformat und settextcolor durchsetzt ist, usw.

Nicht dass ich euch reinreden will, aber das sieht für mich alles sehr nach unkoordinierter Bastelei aus.

Mr X

Der Netzwerktreiber wird grad erst geschrieben; Dass der nicht besonders "schön"/funktiosfähig ist ist daher wohl eher nicht verwunderlich. Wenn Du dich damit auszukennst, wärst Du sicher eine große Hilfe bei der Entwicklung dieses Treibers...

Das settextcolor und printformat wird wohl der Übersichtlichkeit dienen.

Nicht dass ich euch reinreden will

Was heißt reinreden... Du kannst gerne mitmachen Schau doch mal im IRC vorbei...

Mr X schrieb:

Der Netzwerktreiber wird grad erst geschrieben; Dass der nicht besonders "schön"/funktiosfähig ist ist daher wohl eher nicht verwunderlich. Wenn Du dich damit auszukennst, wärst Du sicher eine große Hilfe bei der Entwicklung dieses Treibers...

Ich kenne mich ein wenig damit aus, zwar nicht mit dem RTL, aber Netzwerk-Treiber funktionieren nach oben hin alle ähnlich: sie haben alle eine Init, eine Send und eine Receive Funktion. Interrupt-Handling und das Weiterreichen von Paketen sollte der Treiber besser nicht selbst übernehmen. In diesem Sinne vermisse ich auch Modularität in eurem Projekt, ohne die ihr irgenwann den Überblick verlieren werdet. Gleiches gilt für Protokollstacks. Hier wird Modularität und Layering extrem wichtig, weil z.B. IP/TCP auch von WLAN, PPP, und anderen Paketdiensten "gefüttert" werden kann. Üblich für sowas sind Dispatcher-Module, also Code der dynamisch Protokolle an die Netzwerkinterfaces ankoppelt.

Mr X schrieb:

Das settextcolor und printformat wird wohl der Übersichtlichkeit dienen.

Nicht der Übersichtlichkeit des Codes
Debug-Ausgaben könnt ihr z.B. über define oder Flags steuern. So wie es jetzt ist, müsst ihr später alles auskommentieren.

Mr X schrieb:

Nicht dass ich euch reinreden will

Was heißt reinreden... Du kannst gerne mitmachen Schau doch mal im IRC vorbei...

Danke für die Einladung, aber ich bin kein IRC-Fan und ausserdem ein sehr schlechter Teamplayer. Ich beschränke mich darauf, euch zu kritisieren, wenn mir etwas auffällt.

Edit: die schlimmsten Typos beseitigt

Erhard Henkes

@Z: Wir schätzen konstruktive Kritik. Daher bitte weiter machen. Zuständig für den Bereich Netzwerktreiber ist momentan übrigens 'tty'.

Wenn Du die Übersicht hast, könntest Du deine Kraft auf den USB-EHCI-Treiber lenken (ehci.c). Da schätze ich jede konkrete Unterstützung.

Debug-Ausgaben könnt ihr z.B. über define oder Flags steuern. So wie es jetzt ist, müsst ihr später alles auskommentieren.

Das ist richtig. Dafür verwenden wir folgenden Mechanismus:

#ifdef _DIAGNOSIS_
settextcolor(2,0);
printformat("%X dev: %x vend: %x\t",
           ( pciDev_t*)element,
           ((pciDev_t*)element)->deviceID,
           ((pciDev_t*)element)->vendorID);
settextcolor(15,0);
#endif

_DIAGNOSIS_ wird momentan in os.h gesetzt.

Erhard Henkes

Rev. 146:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=146

in ehci.c und paging Änderungen.

Dieses merkwürdige Phänomen, das MS VPC und Sun VB nach einigen Taskwechseln stoppen, obwohl real hardware tapfer läuft, ist wieder da! Bitte suchen helfen.

Ich habe den Diagnosis-Modus angeschaltet (kann man in os.h abschalten).

Mr X

So... Nachdem ich heute in das Projekt bei Sourceforge aufgenommen wurde gibts hiermit:

Rev. 147
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=147

zzz_alternative_User-Programme entfernt
user/user_test_c/build.bat geändert
user/user_test_c/mingw32-make.exe entfernt

Mr X

Rev. 148
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=148

user/user_test_c/makefile geändert, sodass es ohne msys funktioniert und die userlib nicht mehr im gleichen Ordner liegen muss
user/user_test_c/userlib.c/.h gelöscht, da nicht mehr nötig

EDIT: Das makefile macht auf manchen Systemen derzeit noch Probleme...

Mr X

Rev. 149
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=149

Diagnosis-Ausgabe deaktiviert
user/user_test_c/makefile korrigiert
kernel/task.c und kernel/fat12.c geändert, damit man mit -Wshadow kompilieren kann

Mr X

Rev. 150
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=150

neues makefile: geht (nur) ohne msys

MSYS unbedingt aus dem PATH nehmen!

Erhard Henkes

Rev. 151:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=151

- kernel_pd in task.c verwendet (bisher war dort NULL verwendet worden für das kernel PD)

Mr X

Rev. 152:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=152

TTT 0.41: Macht Gebrauch von der Compileroption -Wshadow, entsprechende Änderungen am Code

Badestrand

Erhard Henkes schrieb:

- kernel_pd in task.c verwendet (bisher war dort NULL verwendet worden für das kernel PD)

War aber kein Bug, sondern ein Feature.. Ne im Ernst, wollte das Kernel-PD private lassen. Ist aber irgendwie doch doof, ich ändere es die Tage mal, macht auch den Code ein bissl kürzer.

Erhard Henkes

Rev. 153:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=153

Dank des Hinweises von +gjm+ wurde endlich das Sun VB / MS VPC Problem gefunden.
Ich habe Datum/Zeit auskommentiert, bis die Funktion in Ordnung gebracht ist.

InitEHCI habe ich ebenfalls auskommentiert, da ich dies für meine Tests benötige.
Wenn jemand da mithelfen will, in pci.c aktivieren.

Mr X

Rev. 154:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=154

makefile aufgeräumt
user_tools ausgelagert nach user/user_tools und makefiles darauf angepasst

Anmerkung (ehenkes): Super! Nun muss man nicht nach jeder Änderung die userlib.h/c kopieren. Arbeitserleichterung und eine Fehlerquelle weniger.

Erhard Henkes

Rev. 155:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=155

- Fehler in time.c in Fkt. getCurrentDateAndTime behoben.

Damit ist ein wichtiger Fehler (buffer overflow) verschwunden, der von Sun VB und MS VPC sensibel detektiert wurde.

Dank an +gjm+ für den Fehlerhinweis!

Erhard Henkes

Rev. 156:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=156

- Fehler in ehci.c behoben
- ehci.c: die 6 Interrupt-Bits in USBINTR auf 0 gesetzt (wenn alle 6 gesetzt sind, kommen keine Tastenanschläge mehr durch)

Tests auf realem PC und Sun VB bezüglich USB EHCI: ok

Rev. 157:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=157
Zwischenschritt bei ehci.c

Rev. 158:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=158
Zwischenschritt bei ehci.c

Rev. 159:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=159
Zwischenschritt bei ehci.c