Sourcecode Fortschritt
-
Rev. 132:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=132pci.c: USB EHCI: Einstieg in Daten-Ermittlung (z.B. OpRegs Adresse, siehe: http://www.c-plusplus.net/forum/viewtopic-var-t-is-253016-and-start-is-39.html)
-
Rev. 133:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=133- paging.c: bool paging_do_idmapping( uint32_t phys_addr ) versuchsweise ab 0xC0000000 (Grund: manche MMIO beginnen ab 0xD....... oder 0xE.......)
- ckernel.c:int main() { init(); pODA->Memory_Size = paging_install(); printformat( "\n\nMemory size: %d KB\n", pODA->Memory_Size/1024 ); heap_install(); pciScan(); // scan of pci bus; results go to: pciDev_t pciDev_Array[50]; (cf. pci.h) tasking_install(); sti();
pciScan direkt hinter heap_install(). In pciScan() werden MMIO (USB EHCI, Netzwerkarte ID-gemappt.
Mal sehen, ob es klappt oder #PF hagelt?
-
Rev. 134:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=134Für unsere verehrten User:
void clear_screen() <--- TODO: nur oberen Bildschirmbereich löschen.
void gotoxy(unsigned char x, unsigned char y)
-
Rev. 135:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=135userlib.h/c: clear_screen() umgestellt auf Löschen der ersten 46 Zeilen (User-Bereich).
-
Rev. 136:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=136- kleine Verbesserungen nach cppcheck
- c99 im makefile bei user ergänztRev. 137:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=137ext in paging.c wieder eingefügt, ansonsten Error-Meldung.
-
Rev. 138:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=138neu: ehci.c (als Keimzelle für den USB 2.0 Host Controller) vergessen worden!
userlib.h/.c: clearScreen(backcolor)
flpydsk.c: Zählervariable versuchsweise im Schleifenkopf definiert (c99 style)
-
Rev. 139:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=139- ehci.c war vergessen worden, jetzt dabei
- fat12.c auf c99 umgestellt
-
Rev. 140:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=140pci.c und initrd.c auf c99 umgestellt (Zähler im Schleifenkopf)
-
Rev. 141
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=141rtl8139.c, util.c und userlib.c auf c99 umgestellt
-
Rev. 142:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=142Fehler in clear_userscreen (video.c) korrigiert
-
Rev. 144:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=144ehci.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)
-
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=145Jede Quellcodedatei die ich bisher von euch gesehen habe (diese z.B.) sieht so furchtbar unvollständig aus. ihr arbeitet wohl an 100 Baustellen gleichzeitig.
-
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.
-
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
-
@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.
-
Rev. 146:
http://prettyos.svn.sourceforge.net/viewvc/prettyos?view=rev&revision=146in 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).
-
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=147zzz_alternative_User-Programme entfernt
user/user_test_c/build.bat geändert
user/user_test_c/mingw32-make.exe entfernt