Sourcecode Fortschritt
-
version = "0.0.2.243 - Rev: 1090"
tcp.c: tcp_sendReset(tcpConnection_t* connection, tcpPacket_t* tcp, bool ack, uint32_t length)
-
Version 0.0.2.244:
- Ramdisk nicht mehr an 4 KiB-Grenzen ausgerichtet
- Erstellen und Starten von Tasks getrennt:
-> Race-Condition beim Warten auf VM86-Tasks behoben: Probleme auf bestimmten Systemen mit VBE sollten damit behoben sein
-> Race-Condition beim Erstellen von Tasks mit eigener Konsole behoben: Selten auftretenes Erscheinen von Text in der falschen Konsole sollte damit behoben sein.
- VM86-Monitor überarbeitet
- APM-Code überarbeitet: Läuft nun unter Qemu, Bochs und VBox, nicht aber auf VPC und echter Hardware. Zum Testen Zeile 131 in power_management.c ändern
-
Version 0.0.2.245:
- Bessere logische Trennung zwischen Tasks, Prozessen und Threads (Vorschlag von kosmick):
-> Task: Allgemeine Containerstruktur für Prozesse und Threads
-> Prozess: Task in eigenen Paging-Context
-> Thread: Task im Context des Erstellers, Abhängig vom Ersteller
- Memory-Übersicht erweitert
- Bugfix: Shell-Prozess wird nicht mehr gestartet, wenn Shell.elf nicht gefunden werden konnte
-
version = "0.0.2.246 - Rev: 1093"
DHCP gelingt nun auch unter Emulation mit Qemu.
Foto: http://www.henkessoft.de/OS_Dev/Bilder/DHCP_on_Qemu.PNG
qemu-batch:
del serielleSchnittstelle1.txt qemu.exe -fda G:\OSDev\PrettyOS\trunk\Source\FloppyImage.img -soundhw pcspk -net nic,model=rtl8139 -localtime -net user -net dump,file=netdump.pcap -serial file:serielleSchnittstelle1.txt
-
version = "0.0.2.247 - Rev: 1094"
list.c kleine Korrektur
-
version = "0.0.2.248 - Rev: 1095"
list.h/c und ring.h/c getrennt.
ring.h/c wird bisher nur in scheduler.c eingesetzt und wurde von MrX speziell dafür entwickelt.
-
Version 0.0.2.249:
- ring.h/c comittet (hat ehenkes vergessen)
- Neuer Interrupt-Code: Mehrfachbelegung von IRQs möglich, Interrupt-Handler mit anderen Prototypen (z.B. für PCI-Geräte oder für CDI) möglich. Benutzung des Interrupt-Status-Bits von PCI erstmal auskommentiert.
-> Es sollten nun mehrere baugleiche Netzwerkkarten zugleich unterstützt werden. Zumindest theoretisch.
- CDI-Implementation deutlich erweitert - Es ist nun möglich, den e1000-CDI-Treiber zu kompilieren und in den Kernel zu linken
-
version = "0.0.2.250 - Rev: 1097"
Netzwerkausgaben arp, dhcp, udp hinter debug (os.h)
-
version = "0.0.2.251 - Rev: 1098"
tcp-Ausgaben hinter debug (os.h: _TCP_DEBUG_)
Screen Photo (PrettyOS emuliert mit qemu. Erfolgreiches DHCP und Ausführung von browser.elf und starwars.elf in eigener jeweils separater Konsole): http://www.henkessoft.de/OS_Dev/Bilder/rev.1098.PNG
-
version = "0.0.2.251 - Rev: 1099"
browser.elf verallgemeinert: Man kann nun eine IP-Adresse (Zahlenwerte) eingeben.
Tipps:
82 100 220 68 goneo.de 65 55 175 254 bing.com 209 85 149 105 google 188 40 141 82 c-plusplus.net
-
Version 0.0.2.252:
- Listen nun doppelt verkettet
- Linkerscript aufgeräumt
- strstr im Userspace implementiert
-
Rev. 1101; 0.0.2.253:
* Workaround DNS Resolver (hack, proof of concept)
Anmerkung (ehenkes):
- browser.c mit Auflösung von Namen (thx to Cuervo)
- TCP beendet manchmal nicht, wenn TCP_DEBUG nicht eingeschlatet ist
-
version = "0.0.2.254 - Rev: 1102"
Experimentelle Version:
- zusätzliche Sicherheits-Timeouts angestoßen bei Übergang zu CLOSE_WAIT und zu FIN_WAIT_1 (nicht schön)
- Leider treten nun vermehrt #PF auf, z.B. beim Erfolgen des Timeouts.
- resolve.php unter tools/ (wurde von Cuervo erstellt)
-
version = "0.0.2.255 - Rev: 1103"
version = "0.0.2.256 - Rev: 1104"
tcp.c: stabiler, aber leider immer noch #PF bei tcp_deleteConnection (erfolgt exakt beim timeout)
Foto: http://www.henkessoft.de/OS_Dev/Bilder/rev.1104_PF.PNG
static void scheduledDeleteConnection(void* data, size_t length) { if ( (*(tcpConnection_t**)data) && (deleteProtection != (*(tcpConnection_t**)data)->ID) ) { tcp_deleteConnection(*(tcpConnection_t**)data); } }
-
version = "0.0.2.257 - Rev: 1105"
version = "0.0.2.258 - Rev: 1106"
#PF durch multiple deleteConnection mittels Variable "deleteProtection" endlich besiegt.
Warum sind die Verbindungen bei einer Wiederholung so langsam?
Anmerkung: Nun kommen neue #PF (browser.elf, aber auch vom kernel, nun aber nicht mehr tcp_deleteConnection)
-
Version 0.0.2.259:
- Protection-Hack durch list_find ersetzt
- Code aus browser.c, userlib.c und tcp vereinfacht
- srand jetzt einmal beim Start und anschließend nicht mehr aufgerufen
-
Rev. 1108 (0.0.2.260):
* Shell makefile und shell.c aktualisiert (helptext)
* DNS Resolver verhübscht
-
version = "0.0.2.261 - Rev: 1109"
- srand nur einmal in ckernel.c ist ok
- rand() im Kernel repariert
-
version = "0.0.2.262 - Rev: 1110"
Interface zwischen user app und tcp-Modul beim Senden erweitert um sendBuffer, um Datenmengen, die größer MSS bzw. connection->tcb.RCV.WND sind, segmentiert versenden zu können.
TODO: segmentation / buffering / steering data flow
-
Version mit sendBuffer zum Testen (Tester: Cuervo, ehenkes):
version = "0.0.2.263 - Rev: 1111" (Fehler)
version = "0.0.2.264 - Rev: 1112" (Fehler: 2. abgeschnittenes Paket kommt nicht an)
version = "0.0.2.265 - Rev: 1113" (funktioniert, man muss nur noch alle Pakete im sendBuffer "flushen" mittels dummy schicken.)version = "0.0.2.266 - Rev: 1114" ("flush" des sendBuffer erfolgt nun ohne dummy senden.)
Mit dem Programm rt.elf kann man beispielhaft testen (schickt langen lateinischen Text "lorum ipsum").
memshow (util.c) wurde erweitert mit bool alpha, sodass man wahlweise auch Texte zeigen kann (siehe auskommentierten Code in tcp_usend).
PrettyOS ist Server (passive open):
cmd: telnet 127.0.0.1 8080 (client erhält den Text)
qemu-batch:
del serielleSchnittstelle1.txt
qemu.exe -fda G:\OSDev\PrettyOS\trunk\Source\FloppyImage.img -net nic,model=rtl8139 -redir tcp:5023::23 -redir tcp:8080::80 -localtime -net user -net dump,file=netdump.pcap -serial file:serielleSchnittstelle1.txt
