Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Themen - kevin

Seiten: [1] 2
1
tyndur / Der große tyndur-Blog-und-Twitter-Ersatzthread
« am: 09. April 2015, 23:53 »
Mir ist gerade danach, ein bisschen mehr Hintergrund zu meinen Andeutungen von gestern zu geben, ohne dass ich allerdings unbedingt einen kompletten Lagebericht wie für den Status-Thread passend zusammenstellen will. Daher hier mal ein Thread für alles mögliche und unmögliche, das in irgendeinem Zusammenhang mit tyndur steht, vielleicht sogar aktuell ist und unbedingt in die Welt raus muss, vom Einzeiler bis zum Roman. Kommentieren ist ausdrücklich erlaubt.

Gestern habe ich mir kedit-Verbesserungen gewünscht, um Treiber debuggen zu können. Vielleicht ist der Zusammenhang da nicht auf Anhieb klar, und außerdem möchte ich nicht den Eindruck erwecken, dass ich einfach nur die ganze Arbeit von anderen gemacht sehen will [1].

Ich komme wohl nicht drum herum, bei XanClics USB-Patches anzufangen, an denen er in den letzten paar Tagen geschraubt hat. Diese Chance, ihm schonungslos seine Fehler aufzuzeigen, konnte ich mir natürlich nicht entgehen lassen. ;) Und so habe ich mein gutes altes, momentan anderweitig unbenutztes Thinkpad T500 ausgegraben und den USB-Treiber darauf losgelassen. Mit Erfolg, das hat nämlich erstmal ein paar Bugs aufgedeckt, aber nach ein, zwei Tagen hat alles soweit funktioniert und ich kann jetzt tyndur vom USB-Stick booten. Ziemlich coole Sache.

Nun da ich eine Möglichkeit hatte, tyndur ziemlich leicht auf echter Hardware zu testen, ohne ständig zu rebooten oder CDs zu brennen, war natürlich nicht der nächste Gedanke nicht fern: Wäre doch nett, wenn der Rest von diesem Stück Hardware auch funktionieren würde. Wir haben ziemlich viele Treiber, die zwar im Emulator tun, aber auf diesem Laptop irgendwie doch nicht: Da wären AHCI und hdaudio, und wir haben einen Treiber für e1000, aber nicht für den vermutlich recht ähnlichen e1000e.

Aber selbst einen USB-Stick ständig umzustecken und nach jeder Debugging-Änderung ein neues Image draufzuspielen war mir mit der Zeit dann doch noch zu umständlich. Stattdessen habe ich mir Compiler, binutils, tyndur-libc und libcdi auf das Image gepackt, dazu noch den Quellcode von den Treibern, und versuche jetzt, die Probleme an Ort und Stelle auf dem Laptop zu debuggen. Mit kedit am Code rumpfuschen, durchbauen, probieren, Treiberprozess wieder killen und von vorne. Geht wesentlich schneller, und selbst die ab und zu nötigen Reboots, weil der ext2-Treiber über den Jordan gegangen ist (oder der zu debuggende Treiber die Konsole so vollspammt, dass man nichts mehr erkennen kann ;)), ändern da nichts daran.

Nur macht das Editieren mit kedit halt nur bedingt Spaß, wenn man eine Zeile nicht einfach mal veschieben kann, sondern sie löschen und an anderer Stelle neu tippen muss... Da fängt man auf einmal an, den Code strategisch zu editieren, um ja so wenig wie möglich verschieben zu müssen. Deswegen die Frage, ob da nicht nebenher jemand was dran machen will, während ich noch an den Hardwaretreibern hänge.

Die andere Möglichkeit, sich an der Hardware-Offensive zu beteiligen, wäre natürlich, einfach mal selbst tyndur auf echte Hardware loszulassen und schauen, was alles tut und wo es noch etwas zu tun gibt (und es dann natürlich auch hier oder im IRC mit uns zu teilen!). Für CD gibt es nach wie vor die Nightlies von LittleFox, das USB-Image muss im Moment noch von Hand aus Max' Branch gebaut werden.

Soweit mal für heute mit dem ausführlichen Einstiegsbeitrag, in den nächsten Tagen gibt es dann wahrscheinlich eher die kürzeren Updates.


[1] Der Eindruck wäre natürlich trotzdem nicht hundertprozentig falsch... ;)
2
tyndur / kedit aufbohren
« am: 08. April 2015, 21:27 »
Von euch kann nicht zufällig jemand Pascal und hätte Lust, den tyndur-Texteditor kedit ein bisschen aufzubohren? Nachdem ich den in den letzten Tagen ab und zu benutzt habe, um Debugcode in Treiber einzubauen, ist mir doch aufgefallen, dass es da noch Verbesserungspotential gibt. ;) Vor allem sowas wie Copy&Paste, eine Suchfunkion und eine Möglichkeit zu einer bestimmten Zeilennummer zu springen wären echt geschickt.
3
tyndur / CDI: AHCI-Treiber
« am: 28. December 2014, 20:01 »
Ich bin mir nicht sicher, ob alle, die CDI benutzen, auch auf der Mailingliste sind, deswegen auch hier nochmal ein kurzer Hinweis: Ich habe auf cdi-devel einen AHCI-Treiber gepostet, der gerne erstens ein Review bekommen und zweitens auch in anderen Betriebssystemen getestet werden würde. ;)

Hier der Link zum Cover Letter: http://list.tyndur.org/pipermail/cdi-devel/2014-December/000264.html

Für alle anderen, die hier nur aus Interesse an týndur mitlesen: Die OS-spezifischen Patches dafür liegen auch schon bereit, dauert also hoffentlich nicht mehr lang. :)
4
Softwareentwicklung / Arbeiten mit Strings in C
« am: 07. March 2011, 23:03 »
char *fdisk_string = "fdisk ";
strcat(fdisk_string, install_device);
Keine gute Idee. Oder was meinst du, welcher Speicher da für den zusammengesetzten String benutzt wird...?
5
Das Wiki / Interwikifikation
« am: 05. February 2011, 12:31 »
Falls es das Wort in $SUBJECT überhaupt gibt... ;)

Mittlerweile sind Interwiki-Links zwischen Lowlevel und osdev.org eingerichtet, was bedeutet, dass man z.B. im Lowlevel-Artikel Speicherverwaltung [[en:Memory Management]] eintragen kann und daraus wird dann der "English"-Link in der linken Leiste, der auf den passenden osdev.org-Artikel verweist. Umgekehrt kann man im osdev.org-Wiki über [[de:Artikelname]] auf den Lowlevel-Artikel verweisen.

Was jetzt noch fehlt, ist, dass diese Verweise auch tatsächlich in allen Artikeln eingebaut werden, die in beiden Wikis existieren. Ich habe gestern schon mit ein paar Artikeln angefangen, aber Unterstützung ist mehr als willkommen. Wenn jeder ein paar Artikel macht, sind wir schnell durch.
6
tyndur / RPC-Performance
« am: 15. March 2010, 16:34 »
bluecode hat mich grad aus Versehen im IRC daran erinnert, dass ich mal gesehen habe, dass tyndur beim Durchführen der RPCs ein paar komische Sachen machen, die Performance kosten könnten. Konkret erinnere ich mich, dass der Ablauf für den synchronen Fall irgendwie so aussieht:

Anfrage senden ------------------> (spezifischer RPC-Handler)
                                               |
(Antworthandler) <----------------  Antwort senden
      |
(Handler fertig) ---------------->  (Handler fertig)
                                               |
Antwort verarbeiten <--------------------------+

Die Pfeile nach links/rechts sind dabei jeweils ein Taskwechsel. Das geht mit Sicherheit besser. Und ich könnte mir vorstellen, dass man bei genauerem Hinschauen noch mehr Fälle findet, wo die Kommunikation umständlicher als nötig ist.

Hat zufällig jemand Lust, sich das näher anzuschauen und den Code entsprechend zu verbessern? Unterstützung im Forum und/oder IRC ist natürlich inklusive. :)
7
tyndur / Release: 0.2.2
« am: 25. December 2009, 22:02 »
Wir haben uns entschlossen, den heutigen Stand von tyndur 0.2.2 als Release zu veröffentlichen:

Die folgenden Abschnitte geben eine kurze Einführung für alle, die mit der Benutzung von tyndur nicht ganz so vertraut sind.

Der Bootvorgang
Der Bootvorgang von tyndur läuft grob in zwei Phasen ab: tyndur benutzt Multiboot, um den Kernel und einige erste Module zu laden (z.B. Platten- und Dateisystemtreiber), so dass Zugriff auf das eigentliche tyndur-Dateisystem möglich ist. Diese Module werden von GRUB geladen und ihr Aufruf kann deshalb im Bootmenü geändert werden. Anschließend lädt servmgr die Konfiguration vom Dateisystem und lädt weitere Module nach (z.B. Konsole oder Netzwerktreiber).

Damit servmgr das System booten kann, braucht er die Angabe des tyndur-Dateisystems als Parameter (vergleichbar zu root=... für Linux). Der im Bootmenü voreingestellte Pfad beginnt mit ata:/ata00_p0 für das Festplattenimage und ata:/cdrom für die Live-CD. Insbesondere bei der Live-CD kann es nötig sein, diese Einstellung zu ändern, wenn der Rechner über zwei CD-Laufwerke verfügt und das falsche als ata:/cdrom benutzt wird. Beispiele für mögliche Angaben:

  • ata:/ata00_p0 steht für die erste Partition auf einer Festplatte an Primary Master
  • ata:/atapi10 steht für ein CD/DVD-Laufwerk an Secondary Master
  • ata:/ata11 steht für ein Dateisystem auf einer unpartitionierten Festplatte an Secondary Slave
  • ata:/cdrom steht für das "erstbeste" CD/DVD-Laufwerk
Manchmal kommt es bei der Benutzung von DMA mit dem ata-Modul zu Problemen (insbesondere mit VirtualBox). In diesem Fall kann es helfen, die ata-Kommandozeile im Bootmenü auf "module /modules/ata nodma" zu ändern.

Terminal und Shell
Wenn servmgr alle Module geladen hat, stehen mehrere virtuelle Terminals zur Verfügung. Standardmäßig kann auf den ersten vier Terminals eine Shell gestartet werden. Die Terminals können über Alt-F1 bis Alt-F4 ausgewählt werden. Alt-F9 wählt das Service-Terminal aus, auf dem von servmgr geladene Treiber ihre Meldungen ausgeben. In den Terminals kann mit Shift-Bild Auf/Ab gescrollt werden.

Zur grundlegenden Orientierung im Dateisystem sei gesagt, dass sich ausführbare Dateien an drei verschiedenen Stellen befinden: Zunächst ist das file:/apps, das alle Anwendungsprogramme des Kernsystems enthält. Das zweite ist file:/system/lpt-bin, das die ausführbaren Dateien per lpt installierter Pakete enthält - genauergesagt enthält es symbolische Links auf die eigentlichen ausführbaren Dateien unter file:/packages. Beide bereits genannten Verzeichnisse sind in PATH, die Programme können also ohne explizite Pfadangabe gestartet werden. Schließlich existiert noch file:/modules, das Treiber und sonstige Services enthält.

Um ein Programm im Vordergrund zu starten, gibt man seinen Dateinamen ein (wenn es weder im aktuellen Verzeichnis noch in PATH liegt, den Pfad zur Datei). Um es im Hintergrund zu starten (empfiehlt sich für Servies aus file:/modules), wird der Befehl start benutzt (z.B. "start /modules/ramdisk").

Dateisystem und Pfade
Die Pfade, die unter tyndur Verwendung finden, unterscheiden sich ein wenig von den üblichen Konzepten und sind daher auch eine kurze Erläuterung wert. Wie man bereits am Dateinamen "file:/apps/sh" erkennt, bestehen Pfade anders als unter Unix nicht nur aus dem Verzeichnis und einem Dateinamen, sondern auch noch aus einem dritten Teil, der angibt, welcher Service die Datei zur Verfügung stellt. Soweit ist das Konzept noch ganz grob mit Laufwerksbuchstaben unter DOS vergleichbar.

Das Besondere an tyndur-Pfaden ist, dass sich diese Pfade zu längeren kombinieren lassen: Während "ext2:/" noch unvollständig wäre, ergibt es kombiniert mit dem Pfad zu einer Festplattenpartition schon sehr viel mehr Sinn: "ata:/ata00_p0|ext2:/". Der Aufbau der Live-CD erzeugt dabei mehrfach kombinierte Pfade: "ata:/cdrom|iso9660:/hd.img|ramoverlay:/cached|ext2:/" bedeutet, dass sich auf dem Laufwerk ata:/cdrom ein ISO-9660-Dateisystem befindet, auf dem ein Image hd.img liegt, über das wiederum eine Ramdisk gelegt wird (damit auf das Dateisystem geschrieben werden kann, obwohl es sich um eine CD handelt), die schließlich ein ext2-Dateisystem enthält.

Um solch umständliche Pfade zu vereinfachen, existiert der Service file, der ein Alias für Pfade bereitstellt. Die Zuordnung der Pfade ist auch auf dem Service-Terminal sichtbar.

Netzwerk
Beim ersten Start des Systems wird die Netzwerkkonfiguration gestartet. Falls ein passender Treiber für die Netzwerkkarte verfügbar ist (rtl8139, sis900, e1000, ne2k, pcnet), wird er automatisch erkannt. Die Einstellungen für die IP-Adresse und den Gateway müssen evtl. angepasst werden. Sie sind so voreingestellt, dass sie mit den Standardeinstellungen von qemu funktionieren. Als DNS-Server wird OpenDNS verwendet (kann durch einen Parameter "ns=a.b.c.d" beim Aufruf von tcpip geändert werden).

Wenn eine Internetverbindung besteht, ist ein schneller Weg, um das Netzwerk zu testen, eine DNS-Adresse aufzulösen: "cat tcpip:/dns/www.tyndur.org". Es ist auch möglich eine einfache telnet-artige Verbindung zu einem anderen Rechner aufzubauen: "pipe tcpip:/192.168.1.1:1234". Die Verbindung wird beendet, wenn "EOF." auf einer eigenen Zeile eingegeben wird.

Software bauen
Um auf tyndur Software zu entwickeln (oder zumindest zu kompilieren) stehen gcc für C-Programme, FPC für Pascalprogramme sowie nasm, yasm und fasm für Assembler zur Verfügung. Auf der großen Variante der Live-CD sind diese alle bereits vorinstalliert; in der kleinen Variante oder auf das Festplatten-Image können sie nachinstalliert werden. Beispielhaft die Installation von gcc und yasm:
# lpt scan
# lpt get gcc
# lpt get yasm

Wenn die Compiler und Assembler installiert sind, können sie wie gewohnt benutzt werden (allerdings ist etwas Geduld nötig, die Compiler gehen sehr gemächlich zu Werke). Als Editoren stehen kedit sowie nano zur Verfügung (letzterer muss ggf. per lpt nachinstalliert werden). kedit beherrscht Syntaxhighlighting, das per F8 aktiviert werden kann. Als Versionsverwaltungssystem kann Subversion benutzt werden.

Programme, die aus mehr als einer Datei bestehen, werden am besten mit "build" gebaut. Es sammelt Dateien aus einer Verzeichnisstruktur wie für den tyndur-Code verwendet zusammen und baut daraus eine Binary, die "run" genannt wird. Als einfaches Beispiel wollen wir die tyndur-Shell neu kompilieren:
# svn co svn://tyndur.org/tyndur/tags/0.2.2/src/modules/c/shell
# build

Es geht mit ein wenig Geduld allerdings auch etwas umfangreicher, nämlich unter tyndur einen tyndur-Kernel bauen (dauert gut 5 bis 10 Minuten). Die Besonderheit dabei ist, dass nicht die normale Standardbiblithek benutzt werden darf (deswegen build -k), sondern diejenige, die auch beim Bauen unter Linux verwendet wird (deswegen checken wir sie extra aus). Insgesamt sieht das folgendermaßen aus:
# mkdir kernel
# cd kernel
# svn co svn://tyndur.org/tyndur/tags/0.2.2/src/include
# svn co svn://tyndur.org/tyndur/tags/0.2.2/src/lib
# svn co svn://tyndur.org/tyndur/tags/0.2.2/src/kernel
# cp kernel/src/kernel.ld .
# build -k
8
tyndur / Tester gesucht - die 0.2.2 steht an
« am: 14. December 2009, 00:36 »
Es ist mal wieder soweit, das traditionelle Weihnachtsrelease steht vor der Tür. Und damit auch die Beta- und RC-Phase, die jedem unserer Releases vorangeht. Unser grober Plan ist heute die erste und hoffentlich einzige Beta, nächstes Wochenende dann der RC 1, den wir pünktlich zu Weihnachten in 0.2.2 umbenennen wollen.

Zum Testen stehen dieses Mal ein Festplattenimage und eine Live-CD zur Verfügung, unter folgenden URLs:

Bitte beachtet, dass die lpt-Repositories noch nicht auf dem aktuellsten Stand sind, das wird sich im Laufe der nächsten Woche dann ändern. Bis dahin bekommt ihr dort noch Software auf dem Stand von 0.2.1 (die zwar ohne weiteres laufen sollte, aber eben die Verbesserungen nicht nutzt).

Wir wären für Rückmeldungen über Tests, inbesondere auf echter Hardware, aber auch auf virtuellen Maschine, dankbar und wünschen euch viel Spaß mit dem neuen Spielzeug. ;)
9
Das Wiki / Umstrukturierung des Forums
« am: 10. October 2009, 11:22 »
Im IRC sind wir in den letzten zwei (?) Jahren immer mal wieder auf die aktuelle Forenstruktur zu sprechen gekommen, waren uns eigentlich immer einig, dass sie so keinen Sinn ergibt, aber haben die Sache vor uns hergeschoben. An anderer Stelle hat sich der geschätzte ehenkes nun dafür ausgesprochen, ein eigenes Board für Bootloader einzurichten, was ich mal zum Anlass nehme, endlich mal im Forum eine Diskussion über die Boardstruktur anzufangen.

Vielleicht fangen wir einfach mal an, Vorschläge zu sammeln, was auseinander muss, was zusammen in ein Board gehört und was sonst noch zum Thema einfällt. Anschließend müssen wir eben sehen, wie wir aus den Gedanken etwas stimmiges basteln. Die Punkte, die mir spontan einfallen, wären:

  • "Das Wiki" sollte zu "Lowlevel" oder sowas werden und allgemeine Diskussionen über Wiki, Forum und meinetwegen auch IRC enthalten.
  • Bei vielen Fragen ist es nicht klar, ob sie nach "Lowlevel-Coding" oder "OS-Design" gehören. Wenn man alles, was mit Code zu tun hat, beim Design ausschließt, würde das Board recht leer werden. Es spricht also manches dafür, das nicht so beizubehalten
  • Ich hielte ein eigenes Board für Hardware (abgesehen von der CPU) für hilfreich
  • Wir haben immer wieder allgemeine Programmierfragen, die landen dann entweder in Off Topic oder Lowlevel-Coding. Eigentlich ist es für uns wirklich Off Topic, aber es sind so viele, dass man evtl. darüber nachdenken sollte, dafür ein eigenes Board einzurichten.
  • Resource Center und Tutorial-Diskussionen werden nicht benutzt und sind eigentlich seit dem Wiki überflüssig. Threads löschen? Wegverschieben? Wenn letzteres, wohin?
  • Der Vorschlag, für Bootloader ein eigenes Board zu erstellen, steht im Raum. Ich bin mir nicht sicher, ob ich ihn für glücklich halte, weil fortgeschrittene Bootloader sehr viel mit (monolithischen) Kerneln gemeinsam haben. Was der Absicht nahekommen dürfte wäre aber evtl. eine Unterteilung in Real Mode und Protected/Long Mode. Das wäre dann aber wieder x86-spezifisch. Ansonsten könnte man noch eine Unterscheidung Assembler/Hochsprachen (ich zähle C mal großzügig zu letzteren) treffen. Nicht sicher, wie es am sinnvollsten wäre. Was denkst du dazu, Erhard?
Soweit von meiner Seite. Da es hier um Bikeshedding geht, gehe ich mal davon aus, dass noch genug andere, auch abweichende Meinungen kommen werden. ;)
10
tyndur / Release: 0.2.1
« am: 05. July 2009, 21:56 »
Nachdem es keine Fehlerberichte mehr gab, haben wir uns entschlossen, den RC 2 in die finale Version 0.2.1 umzubenennen. An den Images hat sich damit seit dem letzten RC nichts mehr verändert, aber das lpt-Repository hat noch einmal Neuzugänge verzeichnet: Mit dropbear steht jetzt ein SSH-Client zur Verfügung und wer unter tyndur mit Quellcode hantieren will, der über Hello World hinausgeht, darf sich über einen SVN-Client freuen.

Herunterzuladen gibt es das Release in den folgenden Varianten:

Der Vollständigkeit noch einmal kurz zusammengefasst die interessantesten Neuerungen:

  • lpt-Pakete: lynx ist als Browser neu dazugekommen, die e2fstools erlauben das Anlegen neuer Dateisysteme und Free Pascal wurde auf 2.3.1 aktualisiert. Außerdem sind dropbear als SSH-Client und der Subversion-Client portiert worden.
  • Ein neues Hilfesystem wurde integriert, das den alten help-Befehl ersetzt (nur auf dem Festplattenimage)
  • CD-ROM-Unterstützung
  • UTF-8-Unterstützung (und damit endlich auch Umlaute in Shell, Editor und IRC-Client)
  • Neues Tool build, das einen Quellcode-Verzeichnisbaum baut (braucht einen installierten Compiler)
  • Ein Haufen Fehlerkorrekturen
Viel Spaß!
11
Lowlevel-Coding / PowerPC
« am: 01. June 2009, 14:14 »
Hat zufällig irgendeiner von euch schonmal versucht, einen Kernel für PowerPC zu schreiben und war dabei möglicherweise sogar halbwegs erfolgreich? Ich will mir das schon eine ganze Weile mal näher anschauen (immer nur x86 ist schließlich langweilig), aber ich komme mir ungefähr genauso hilflos vor wie damals als Anfänger. Okay, das ist etwas geschwindelt, von x86 hatte ich nämlich davor schon mehr Ahnung...

Im qemu habe ich immerhin mal ein "Hello World" auf die serielle Konsole rausbekommen, aber selbst dieser Code ist kaputt, weil ich einfach die MMIO-Adresse hartkodiert habe, wo die serielle Schnittstelle unter qemu eben liegt. Theoretisch müsste ich von der Open Firmware rauskriegen, was ich wirklich machen sollte. Wenn mir irgendjemand ersparen könnte, selbst endlos Texte zu wälzen, wäre ich dankbar. ;)

Und ich glaube entsprechend der aktuellen Mode schreibe ich jetzt erstmal ein Tutorial, wie man unter PPC in qemu Hello World ausgibt, basierend auf diesem revolutionären Code:
.global _start
_start:
    lis r3, str@h
    ori r3, r3, str@l
    lis r4, 0x8089
    ori r4, r4, 0x3030
putc:
    lbz r5, 0x0(r3)
    cmpwi r5, 0x0
    beq loop
    stb r5, 0x0(r4)
    addi r3, r3, 1
    b putc
loop:
    b loop

str:
    .ascii "Hello World\n\0"

Bin ich gut oder bin ich gut? :-D
12
tyndur / 0.2.1 - Beta- und RC-Phase
« am: 30. May 2009, 21:25 »
Es ist so langsam mal wieder an der Zeit für ein neues Release. Wie die Versionsnummer 0.2.1 schon verrät hat sich nicht ganz so viel getan wie beim letzten Sprung auf die 0.2, aber auch dieses Mal gibt es wieder einige Neuerungen, die direkt spürbar sind.

Ich will euch nicht lange aufhalten, daher hier die Links zu den Images der 0.2.1 Beta 1:
Kurz zusammengefasst die interessantesten Neuerungen:
  • lpt-Pakete: lynx ist als Browser neu dazugekommen, die e2fstools erlauben das Anlegen neuer Dateisysteme und Free Pascal wurde auf 2.3.1 aktualisiert.
  • Ein neues Hilfesystem wurde integriert, das den alten help-Befehl ersetzt (nur auf dem Festplattenimage)
  • CD-ROM-Unterstützung
  • UTF-8-Unterstützung (und damit endlich auch Umlaute in Shell, Editor und IRC-Client)
  • Neues Tool build, das einen Quellcode-Verzeichnisbaum baut (braucht einen installierten Compiler)
  • Ein Haufen Fehlerkorrekturen
Außerdem sind auch schon ein paar Fehler aufgefallen:
  • Das FPC-Paket funktioniert nicht. fpc stürzt beim Start ab.
  • build ruft fpc mit falschen Optionen auf
  • Die Hilfe stürzt beim Auswählen der "Builtin-Kommandos" gelegentlich ab
  • Die Beschreibung für lpt list ist falsch (zeigt verfügbare Pakete an, nicht installierte Pakete)
  • lpt macht teilweise noch Debugausgaben
  • Das libc-Paket ist nicht aktuell
13
tyndur / 0.3 - Ideen und Ziele
« am: 09. May 2009, 23:18 »
Nachdem wir so langsam auf den letzten Metern für die 0.2.1 sind (unter anderem kommt Unterstützung für CD-ROM und UTF-8 dazu, außerdem ein paar neue lpt-Pakete und eine Ladung Bugfixes), ist es an der Zeit, sich einmal Gedanken zu machen, was die nächsten Schritte sind und wo uns die Zukunft hinführen soll.

Dafür, daß tyndur ein Communityprojekt ist, haben wir in letzter Zeit das Forum vielleicht etwas zu wenig in die Entwicklungen einbezogen. Das möchte ich an dieser Stelle ändern: Was meint ihr, wohin die Reise gehen soll? An dieser Stelle sind spontane und möglicherweise "kreative" Ideen genauso gefragt wie ausgefeilte Vorschläge oder einfach nur Vorschläge für Features oder eine bestimmte Entwicklungrichtung.

Um einen Ausgangspunkt für Ideen zu geben, möchte ich einmal kurz die groben Felder nennen, die ich persönlich sehe:

Kernkomponenten
Dieser Bereich umfaßt den Kernel, Treiber und die libc. Unsere Überlegung war, daß in diesem Bereich die zentralen Änderungen für 0.3 liegen werden. Als Baustellen sehe ich dabei vor allem:

  • Umstellung auf kernel2, d.h. Implementierung der im Vergleich zu kernel noch fehlenden Features und Syscalls
  • Mehr Dokumentation in kernel2, auf tyndur wird oft als Beispiel verwiesen und eines seiner ursprünglichen Ziele ist auch, daß es dabei hilfreich sein soll. In den Code könnte man oft fast eine Art Tutorial als Kommentar einbetten.
  • LostIOv2 als neues, kernelbasiertes virtuelles Dateisystem soll das bisherige LostIO, das im Userspace läuft, ablösen und sowohl eine sauberere Schnittstelle bereitstellen als auch die Performance verbessern
  • Portierung auf amd64 (niedrigere Priorität)
  • Unterstützung für TCP-Server
  • Evtl. mehr Hardwareunterstützung (z.B. Netzwerkkarten)
POSIX und lbuilds
In diesem Bereich geht es darum, existierende Software - vor allem aus dem *nix-Umfeld - auf tyndur zu portieren. Dazu gehört es auch, die POSIX-Emulation in der libc weiter zu vervollständigen oder ganz neue Funktionen einzubauen. An dieser Stelle könnte man unglaublich viel aufzählen, aber wichtig wären mir vor allem:

  • Irgendein Mailclient, z.B. mutt
  • Ein SVN- oder git-Client
Damit könnte man dann theoretisch die tyndur-Entwicklung unter tyndur vorantreiben. ;)

Grafische Benutzeroberfläche
Ja, eine GUI wäre eigentlich auch mal ganz nett. Wirklich konkrete Vorstellungen habe ich dazu noch nicht, aber ich würde mir wünschen, daß sie tastaturfreundlich ist.

Freaky und ich selbst werden neben den restlichen Aufgaben vermutlich kaum die Zeit finden, viel in Sachen GUI zu unternehmen - dazu hat sie im Vergleich zum Rest noch eine zu niedrige Priorität. Wir könnten zwar in allen Feldern Verstärkung gebrauchen, aber ich sag's mal ganz direkt: In Sachen GUI wird nur was passieren, wenn sich ein paar Leute zusammenfinden, die auf diesem Gebiet zusammen was reißen wollen.

Wenn das gegeben ist, dann werden wir sicher auch die nötige Unterstützung geben können, wie man das am besten mit dem Rest von tyndur integriert. Ansonsten könnte die Entwicklung als relativ eigenständiges Projekt mit momentan noch allen Freiheiten laufen - und wer sich als Interessierter meldet, hat gute Chancen, die Sache selbst leiten zu können.

Werkzeuge und Anwendungsprogramme
Dieses Feld umfaßt native tyndur-Programme, bisher in C oder Pascal geschrieben, die dem Benutzer zur Verfügung stehen. Momentan schon  existierende Beispiele sind die Shell, das neue Hilfeprogramm, kedit, kirc, fdisk, build oder lpt. Die meisten dieser Programme könnten Erweiterungen vertragen (welche?) und es ist sicher noch Platz für weitere. Meine Favoriten wären:

  • Ein Installationsprogramm, mit dem man tyndur von einer CD oder Netzwerk auf Platte installieren kann (für die Mutigen unter uns ;))
  • kedit: Markieren von Text, Kopieren/Ausschneiden/Einfügen, Suchen. Syntaxhighlighting für zusätzliche Sprachen (bisher nur C)
  • lpt: Upgrades, evtl. eine TUI  vergleichbar mit aptitude
Das war jetzt einmal mehr oder weniger ein kompletter Braindump von mir zu den nächsten Schritten in Richtung 0.3 - wobei sich manche Punkte davon sicher auch noch auf spätere Versionen verzögern werden. Ich bin gespannt, ob andere das ähnlich sehen oder vielleicht andere gute Ideen aufkommen, worauf man sich konzentrieren könnte.

Außerdem wäre ich natürlich daran interessiert, wer von euch sich vorstellen könnte, im einen oder anderen Themengebiet selbst ein bißchen mitzumachen. Es würde mich freuen, wenn wir ein kleines GUI-Team zusammenbekommen würden - zwei, drei Mann wäre vielleicht realistisch - aber auch in den anderen Feldern gibt es genug zu tun.

Okay, genug geredet, ihr seid dran. Vielleicht bringt ihr ja revolutionärere Ideen zustande als ich. ;)
14
tyndur / Hello World!
« am: 26. April 2009, 11:50 »
Dieser Beitrag wurde mit lynx unter tyndur erstellt. ;)
15
Lowlevel-Coding / BIOS Memory Map
« am: 12. June 2008, 05:16 »
Nachdem ich heute schon so viel gelernt habe, stelle ich hiermit einen Antrag auf noch mehr. Aber zuerst moechte ich meine neueste Erkenntnis mit euch teilen: Wenn man seine Prozessmanagement-Strukturen in den Videospeicher legt, passieren unter Umstaenden nicht so geplante Dinge. ;)

Weiterhin habe ich festgestellt, dass die Memory Map in qemu Loecher hat. Es gibt belegte Bereiche, nutzbare Bereiche und Bereiche, ueber die keine Aussage getroffen wird (der Videospeicher gehoert zu letzterer Kategorie und kernel2 hat per Default erstmal alles frei). Jetzt muss ich also irgendwie diese Loecher stopfen und frage mich: Kann ich eigentlich davon ausgehen, dass die Liste sortiert ist? In qemu scheint das so zu sein, aber das bricht dann garantiert wieder irgendwo, oder?

Hm, okay, ich merke schon, das geht alles in Richtung kaputter Hack. Am besten baue ich das Ding komplett um, dass es auf belegt defaultet. Aber vielleicht weiss ja trotzdem jemand die Antwort. ;)
16
Lowlevel-Coding / sis900: Senden großer Pakete
« am: 17. May 2008, 20:14 »
Leute, streicht euch diesen Tag im Kalender rot an. Das ist vermutlich eine Weltpremiere - taljeth fragt auch mal im Forum nach Hilfe! Die Wahrscheinlichkeit, daß mir jemand helfen kann, dürfte zwar nicht allzu groß sein, aber versuchen kann man es ja mal und es ist auch eine nette Abwechslung zu den ganzen Threads zum Thema "nimm doch bitte GRUB". ;)

Es geht mir also um Netzwerkkarten mit dem sis900-Chipsatz, konkret hat mein Testrechner das Ding onboard auf einem SiS 735-Mainboard. Und weil ich jetzt ganz gern auch unter LOST Netzwerk hätte, habe ich mich vor einer Weile darangesetzt, einen Netzwerktreiber dafür zu schreiben.

Im großen und ganzen tut das auch alles, solange ich nur kleine Pakete bis einschließlich 128 Bytes versende. Sobald ich aber versuche, auch nur ein einziges größeres Paket zu senden, fängt die Karte komplett an zu streiken (ich habe übrigens nicht rausgefunden, wie ich sie aus diesem Zustand ohne Reset-Knopf wieder herausbekommen kann...), d.h. Senden schlägt grundsätzlich fehlt, empfangen wird auch nichts mehr und irgendwann läuft die RxFIFO über.

Code gibt es im WebSVN: Klickst du hier

Irgendjemand eine Idee, woran es liegen könnte?
17
tyndur / Wir suchen...
« am: 09. February 2008, 11:17 »
...weitere Mithelfer.

Bei der ersten Vorstellung des Projekts hatten sich recht viele gemeldet, die zwar grundsätzlich daran interessiert waren, an einem Community-OS mitzuhelfen, die aber an ihren Fähigkeiten gezweifelt haben, im Kernel mitzubasteln.

Jetzt kommt euer Einsatz. LOST hat eine stabile Basis, auf der Userspace-Programme aufsetzen können. Ein vollständiges OS kann eine ganze Menge an solchen Programmen vertragen. Wir suchen also Leute, die sich vorrangig um diese Programme kümmern.

In diesem Thread können einerseits Ideen für Programme gepostet werden, die LOST enthalten sollte. Andererseits könnt ihr hier sagen, daß ihr ein bestimmtes Programm aus dieser Liste, möglicherweise im Team, übernehmen wollt.

Als kleinen Anstoß eine kurze Liste, was denkbar wäre:
  • Texteditor (evtl. auch in Richtung IDE?) [ChristianF]
  • Ein Setupprogramm (Installation und Konfiguration) [Nicolas]
  • fdisk [DarkThing]
  • FTP-Client [nicht vergeben]
  • Hilfesystem [stultus]
  • Treiberschnittstelle (CDI) [janosch] (Team; weitere Meldungen möglich)
  • Erweiterung der Shell [nicht vergeben]
  • curses-Implementierung [ChristianF]
18
tyndur / Bescherung: 0.1.1
« am: 24. December 2007, 23:55 »
Gerade noch pünktlich schenken wir euch das nächste LOST-Release, Version 0.1.1. Der Releasekandidat 5 hat uns schließlich soweit zugesagt, daß wir beschlossen haben, ihn unverändert als Final zu veröffentlichen:

Viel Spaß!
19
tyndur / Und weiter - die 0.1.1 steht an
« am: 10. September 2007, 22:55 »
Mit den RCs der 0.1.0 hat es ja ganz gut geklappt, noch ein paar Fehler einzufangen, bevor wir die Sache offiziell gemacht haben. Deswegen versuchen wir dasselbe Spielchen mit der 0.1.1 einfach noch einmal. Ab sofort (bzw. eigentlich schon gestern) ist der RC1 verfügbar:

Wie gewohnt würden wir vor allem gern Tests auf echten PCs sehen. Als Emulator ist vor allem qemu zu empfehlen (weil der Netzwerktreiber damit funktioniert ;)), aber auch bochs und VirtualBox sollten es tun. VMware funktioniert derzeit leider nicht.

Testberichte in diesem Thread sind willkommen, bei Fehlern gern auch Meldungen in unserem Bugzilla.

Wer Netzwerk mit qemu testen will, folgende Schritte:
1. qemu -fda lost-0.1.1-rc1.img -net nic,model=rtl8139 -net user
2. Den zweiten Bootmenüeintrag wählen (experimentelle Treiber)
3. kirc starten, den IRC-Client für LOST. Server und Port sind auf euirc voreingestellt, ein /join #lost bringt euch also in unseren geliebten Channel
4. Ja, das ist cool, aber vergeßt nicht, auch anderes auszuprobieren ;)

Viel Spaß.
20
Offtopic / wtf?
« am: 20. July 2007, 21:49 »
*test*

Edit: Falls sich jemand wundert, ich wurde gerade mit folgendem Text begrüßt: "Hallo ScAr_TeX, Sie haben 0 Nachrichten, 0 sind neu." Das fand ich leicht beunruhigend. Aber das Posten hat geholfen, daß er mich wieder als mich erkannt hat. ;)
Seiten: [1] 2

Einloggen