4. Sourcecode Fortschritt

Sourcecode Fortschritt

  • E
    Mod

    version = "0.0.2.181 - Rev: 1024"

    list und ring mit ASSERT gesichert (list.c), damit fehlerhafte Parameter sichtbar werden.

    0
  • M

    Version 0.0.2.182:

    - PCI: pci_deviceSentInterrupt implementiert, PCI-Bars 2-6 nur ausgelesen, wenn headerType 0
    - listHead_t in list_t umbenannt
    - CRC nun im RTL8139-Treiber aus empfangenen Paketen entfernt.
    - Dummy.c: Schon wieder reverted. Das ist keine Spielwiese! Zum testen einfach eine neue .c-Datei in other_userprogs anlegen. Das funktioniert viel besser, weil die dann automatisch übersetzt und auf die Floppy gepackt wird.
    - fdir-Anzeige überarbeitet, Code verständlich gemacht
    - Kleinigkeiten

    0
  • E
    Mod

    version = "0.0.2.183 - Rev: 1026" (in ckernel.c: versehentlich 1025)

    tcp: in/out Buffer angefangen

    arp: nicht table, sondern cache (führt zu cache->table, besser als table->table)

    user-prg:
    irc.elf etwas weiter entwickelt.

    0
  • E
    Mod

    version = "0.0.2.184 - Rev: 1027"

    tcpIn_t, tcpOut_t, ... hinzu gefügt.

    Problem: tcp.c, Zeile 432 ff.: Fill in-buffer list arbeitet zu langsam.
    Aktiviert man memcpy(In->data, ...), dann bleibt der starwars-Empfang in Qemu hängen (Test auf einen hohen Dateninput). Kann man event.buffer und In->data (dauerhaft auf dem Heap) kombinieren und das doppelte memcpy sparen?

    Vielleicht benötigen wir auch ein schnelleres memcpy in Assembler.

    beep weg (sehr lästig beim Testen)

    Code läst sich bis -O2 compilieren, dann gehen auch beide memcpy, allerdings nicht mit -O3, dort kommt ein Fehler bei der checksum-Routine.

    0
  • E
    Mod

    Lösungsvorschlag:

    uint16_t udptcpCalculateChecksum(void* p, uint16_t length, IP_t srcIP, IP_t destIP, uint16_t protocol) 
{ 
    updtcpPseudoHeader_t pseudo = { srcIP, destIP, 0, protocol, htons(length) }; 
    uint32_t pseudoHeaderChecksum = 0; 

    for(uint32_t i = 0; i < sizeof(updtcpPseudoHeader_t); i+=2) 
    { 
        pseudoHeaderChecksum += htons(((uint16_t*)&pseudo)[i]); 
    } 

    return internetChecksum(p, length, pseudoHeaderChecksum); 
}
    0
  • M

    Den O3-Fehler kenne ich. Ist afaik ein Bug in GCC 4.4.0, der in gcc 4.4.4? gefixt wurde. Da es aber keinen Grund gibt, mit -O3 zu kompilieren, denke ich, dass ein Workaround nicht nötig ist.

    0
  • M

    Version 0.0.2.185:

    - IRC-Programm verbessert: Joinen mit Strg+J, Senden an #PrettyOS mit Strg+P
    - Padding wird nun in ipv4.c entfernt und nicht mehr (fehlerhaft) in tcp.c.
    - Paket- und Headerlängen in tcp.c und ipv4.c korrekt verwendet.

    0
  • E
    Mod

    version = "0.0.2.186 - Rev: 1029"

    @MrX: hab deinen Vorschlag umgesetzt, aber es besteht ein Zugriffsproblem von user nach kernel heap.

    Experimenteller Zwischenstatus: Übergabe eines Events in tcp.c mit buffer als Zeiger. Ist Array notwendig? Wenn ja, welche Größe?
    Problem: Daten stecken im Kernel Heap. Wie greift man darauf von user-land aus zu? (Erfolgloser Versuch in browser.c, irc und starwars noch unverändert, wieso gibt das keinen #PF?) 🙄

    MrX: Idee, wie man das auflösen kann?

    memcpy durch etwas schnellere Assembler-Version ersetzt.

    0
  • E
    Mod

    Anmerkung aus #lost: wir sollten mehr Unterordner einziehen unter \kernel.

    0
  • E
    Mod

    version = "0.0.2.187 - Rev: 1030"

    - TCP-Datentransfer nun korrekt von kernel nach user
    - TCP-Datentransfer beschleunigt

    0
  • E
    Mod

    version = "0.0.2.188 - Rev: 1031"

    - kleine Änderungen in tcp.c und types.h (connectionID)
    - bei receive FIN,ACK (geht bei browser.c) werden testweise die Pakete in der IN-Queue angezeigt: Seq, len, data (funktioniert!)

    0
  • E
    Mod

    version = "0.0.2.188 - Rev: 1032"

    - irc angepasst, damit ein zufälliger Name (Pretty+Zufallszahl) gebildet wird.

    - Pretty14309 joined
    <Pretty14309>hi
    <ehenkes>test
    - Pretty14309 quit (Client exited)

    - Pretty17705 joined
    <Pretty17705>schon wieder da ^^
    - Pretty17705 quit (Connection reset by peer)

    - Pretty19370 joined
    ...
    - Pretty19370 quit (Connection reset by peer)

    0
  • E
    Mod

    version = "0.0.2.188 - Rev: 1033"

    Hinweis von Kollegen aus #lost auf die Pflicht, sich mit QUIT zu entfernen.
    “A client session is ended with a quit message.”

    Dem kommen wir gerne nach. Kostet aber schon wieder zwei Zeilen.;)

    case KEY_ESC:
{
    char* msgQuit = "QUIT\r\n";
    tcp_send(connection, msgQuit, strlen(msgQuit));
    tcp_close(connection);
    return(0);
}

    - Pretty31812 joined
    <Pretty31812>test auf quit
    - Pretty31812 quit (Life is too short...)

    - Pretty28547 joined
    <Pretty28547>nochmal jetzt mit ESC weg
    - Pretty28547 quit (Life is too short...)

    0
  • E
    Mod

    version = "0.0.2.189 - Rev: 1034"

    - memcpy, memset nun schneller (MrX)
    - irc.c (Nummernausgabe weg)

    0
  • M

    Version 0.0.2.190:

    - console.c: Bugfix: console_clear ändert Textfarbe nicht mehr.
    - memshow: Bugfix bei count%16!=0: Darstellung korrigiert.
    - memsetl durch memset ersetzt (Performance-Hack nicht mehr nötig)
    - optimiertes memset/memcpy auch im Userspace, memsetw ebenfalls optimiert
    - Shell:
    -- Bugfix: Eingabezeile nun korrekt gelöscht.
    -- Bugfix: Cursorposition wird zurückgesetzt, wenn Eintrag mit Pfeiltaste nach unten gelöscht wird.
    - Kleinigkeiten

    0
  • E
    Mod

    version = "0.0.2.191 - Rev: 1036"

    Steuerungsmechanismus window mittels Feedback aus event_issue testweise installiert, um Erfahrung zu bekommen.

    0
  • E
    Mod

    version = "0.0.2.192 - Rev: 1037"

    Gesamtgröße der TCP-Daten in der Event-Queue bestimmt

    0
  • E
    Mod

    version = "0.0.2.193 - Rev: 1038"

    Versuchsweise Steuerung des sliding window mit der Gesamtmenge an TCP-Data (bytes) in der Event Queue des task.

    0
  • E
    Mod

    version = "0.0.2.194 - Rev: 1039"

    tcp ausgaben stark vereinfacht

    0
  • E
    Mod

    version = "0.0.2.195 - Rev: 1040"

    Fehler in TCP korrigiert (z.B. window Steuerung)

    0
Anmelden zum Antworten