Lowlevel
Lowlevel => tyndur => Thema gestartet von: kevin 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]
-
Jetzt kommt euer Einsatz.
Also nicht daß das falsch verstanden wird: Es dürfen sich natürlich nicht nur diejenigen melden, die damals schon mithelfen wollten. Auch wer hier noch relativ neu ist, ist genauso gefragt. LOST soll ein Community-OS sein und es wäre schön, wenn sich eine große Zahl von Mitgliedern der Community finden ließen, die daran teilnehmen wollen.
-
Hi,
Also, wie ihr sicher schon gemerkt habe, helfe ich gerne mit CDI zu entwickeln, da ich es auch schon für mein Betriebssystem am implementieren bin. Ich denke, dadurch, dass Entwickler von mehreren Betriebssystemen daran mithelfen könnte helfen, es Betriebssystemunabhängig zu halten. Man könnte ja mal eine Kategorie in der Wiki anlegen für CDI und es ein wenig dokumentieren. Also ich würde da gerne mithelfen.
-
Vielleicht postet du deinen Vorschlag für den Dateisystem-Teil mal im Forum? Ich schätze mal, hier kommt etwas mehr Feedback.
Wegen der Dokumentation weiß ich nicht, was man außer der doxygen-Ausgabe und vielleicht einer Grobübersicht noch brauchen könnte. Aber du kannst gern mal was im Wiki anlegen, den einen oder anderen Platzhalter werde ich schon auffüllen oder hier und dort eine Ergänzung anbringen.
-
So, zu den LOST-Anwendungen, meld ich mich mal für das Hilfesystem.
-
Vielleicht postet du deinen Vorschlag für den Dateisystem-Teil mal im Forum? Ich schätze mal, hier kommt etwas mehr Feedback.
Wegen der Dokumentation weiß ich nicht, was man außer der doxygen-Ausgabe und vielleicht einer Grobübersicht noch brauchen könnte. Aber du kannst gern mal was im Wiki anlegen, den einen oder anderen Platzhalter werde ich schon auffüllen oder hier und dort eine Ergänzung anbringen.
Endlich mal Feedback mit dem ich was anfangen kann ;)
Ich werde dann gleich mal den FS-Teil hier posten und die Doxygen-Doku könnte ich auch mal wieder online stellen.
-
Ich würde mich für den Texteditor melden.
Gibt es da ein bestimmtes Interface?
-
Schön zu hören. :)
Im Moment steht halt nur die Standard Libc und ein einfaches readline() zur Verfügung. Am besten schaust du mal im IRC vorbei. (Server: irc.euirc.net, Kanal #lost)
-
Grundsätzlich kannst du mit ANSI-Sequenzen arbeiten, um deine Ausgaben zu machen. Wenn du C benutzen willst, willst du dir vermutlich ein kleine Lib für die Textmodusoberfläche schreiben, die die Sequenzen in handliche Funktionen verpackt. In Pascal ist die Unit crt ein Stück weit implementiert.
-
Ich meld mich jetzt mal offiziell für ein fdisk :)
-
Kommt ihr soweit zurecht oder kann man euch irgendwie unterstützen? Wobei ich jetzt vor allem ChristianF meine, DarkThing hatte sein Problem ja schon angesprochen. ;)
-
Ich arbeite mich grad in den vim source ein, um zu schauen, was ich übernehmen kann oder ob ich ihn portieren kann.
-
Naja, die erste ernsthafte Abhängigkeit, die mir da in den Sinn kommt, ist ncurses. Ich hatte bisher nie Lust, diesen Klotz anzupacken und zu portieren, was aber auch daran liegt, daß ich es bisher nicht einmal benutzt habe. Wenn du ncurses portieren würdest, wäre das natürlich ein ganzes Stück Arbeit, aber auch richtig cool und sicher eine lohnenswerte Investition. :)
-
Ich kann es versuchen, kann aber für nichts garantieren.
Sollte ich das nicht hinbekommen, werde ich den Versuch starten, was eigenes zu entwickeln.
Bis dann: stay tuned :-D
Gruß
Christian
-
Das hört sich doch mal interessant an.
Wo kann ich den aktuellen Kernel und die zum Basteln benötigte header finden? Währe auch nett wenn irgendwo beschrieben wird wie man sich ein Programm für lost backen muss!
Wenn ich dass am laufen hätte, könnte ich mir mal überlegen etwas Zeit zu spenden.
Btw: Habt ihr eigentlich schon Grafik am laufen. Sprich vga/vesa? Nicht dass ich da was schreiben will, aber benutzen würde ich es schon gerne. ;)
-
Den ganzen LOST-Code kannst du dir aus unserem Subversion-Repository holen. (Repository: svn://lost-os.ath.cx/lost/)
Wie man das mit dem Programm anstellt sieht man in src/modules/c/getterm ganz gut. Einfach in src/modules/c ein Verzeichnis erstellen, eine Makefile.all rein und dann kanns losgehen. :)
Es existiert ein Treiber für vga, an dem wurde aber seit einiger Zeit nichts mehr gemacht (der Entwickler, der mit dem GUI-Kram angefangen hat, ist nicht mehr aktiv dabei), und somit weiss ich nicht, ob er im Moment noch funktioniert.
-
Unter Mingw bekomme ich die Fehlermeldung dass er den Stack Schutz nicht kennt:
unrecognized command line option "-fno-stack-protector"
Ab welchem GCC ist der Parameter denn vorhanden?
Dann habe ich das "-fno-stack-protector" aus der config entfernt und bin nun bei:
vm86.c:54: warning: alignment of 'bios_data' is greater than maximum object file alignment. Using 16
make[7]: *** [vm86.o] Error 1
Womit ich nicht soviel anzufangen weiß.
Ist das eventuell nur eine geschredderte SVN Version oder wie bekomme ich das unter Mingw zum laufen? Ich werde es später nochmal unter ubuntu testen.
-
Ab welcher Version der Parameter vorhanden ist, weiss ich nicht genau.
Ich bin nicht sicher welche Formate mingw benutzt. Aber probier mal den Crosscompiler von Jidder: http://lowlevel.brainsware.org/wiki/index.php/Crosscompiler_f%C3%BCr_Windows
Ubuntu müsste eigentlich problemlos gehen, solange es keine 64-Bit Version ist (wie es da unter Ubuntu aussieht weiss ich nicht. Ich weiss nur, dass ich bei meinem 64-Bit gentoo einen Crosscompiler benötige).
-
Bisschen spät der Kommentar dazu, aber auch 64-bit Ubuntu geht, ohne gezielt nen crosscompiler gebaut zu haben. Wichtig sind dafür halt nur ein paar weitere Optionen, u.a. -fno-stack-protector. Sollte alles notwendige bereits im svn sein.
EDIT: Dafür machen andere Pakete ärger, mtools musst ich aus den quellen installieren damit make image funktioniert.
-
Ich habe nur einen 32Biter daher auch nur 32 Bit Ubuntu.
Zum laufen bekomme ich es trotzdem nicht:
make --no-print-directory -s makefiles
./buildmk.sh: 36: shopt: not found
./buildmk.sh: 46: source: not found
[: 100: ==: unexpected operator
./buildmk.sh: 133: Syntax error: "(" unexpected
make[1]: *** [makefiles] Fehler 2
make: *** [all] Fehler 2
osbios@c01:~/lost-OS-svn/trunk$
Ich weiß nicht wieso er shopt und source angeblich nicht findet?
-
hängt mit dem Einsatz von dash statt bash als Standardshell zusammen, iirc. Versuch mal /bin/sh zu löschen und auf /bin/bash zu linken, dann sollte alles gehen.
-
Weißt du ob das irgendwelche ungewollten Auswirkungen hat? Ich mein Ubuntu wird nicht zum Spaß dash einsetzten, oder?
-
dash soll angeblich schneller sein. Kann auch gut sein, wenn es dafür nichts mehr kann. ;) Mit bash als /bin/sh wird man jedenfalls definitiv weniger Probleme haben als mit dash, auch mit anderen Projekten. Zusammengefaßt: Nachteil der Rückersetzung ist, daß Skripte etwas langsamer laufen; Vorteil ist, viele Skripte laufen überhaupt erst mit bash.
Übrigens ist mittlerweile eine erste fdisk-Version eingecheckt, vielen Dank an DarkThing. In Sachen Usability (und auch featuremäßig) gibt noch manches zu tun, aber hey, es läuft. :)
-
Nicolas hat sich gemeldet, daß er am Setupprogramm basteln möchte, ich habe die Liste entsprechend aktualisiert. Außerdem habe ich zwei neue Punkte hinzugefügt: Zum einen könnte die Shell ein paar Erweiterungen vertragen, z.B. Dateinamenvervollständigung oder Auswerten von Umgebungsvariablen. Wer sich die Shell anschaut, findet sich auch ein paar andere Sachen, wo er anpacken möchte - so genau wollen wir das gar nicht vorgeben.
Zum anderen drücken wir uns seit Ewigkeiten darum, curses zu portieren bzw. zu implementieren, weil es etwas zu groß wirkt, um mal so nebenbei gemacht zu werden. Allerdings fehlen uns dadurch Ports von vielen Programmen mit Textmodusoberfläche. Falls also jemand Lust hätte, wäre cool. :)
-
Also
da ich ja versuche den VI zu portieren, ist ncurses für das Syntax Higlighting zwingend notwendig.
Deshalb arbeite ich gerade an einer Portierung von ncurses, habe aber wegen meiner Ausbildung nicht sehr viel Zeit und komme deshalb auch nicht so schnell voran, wie ich es gerne hätte. :oops:
Gruß
ChristianF
-
Ah, gut. Das klang beim letzten Mal noch etwas unentschlossener. ncurses ist ja doch ein rechter Brocken, da ist es nur verständlich, wenn es etwas länger dauert (wenn man mal mit dem billigen sis900-Netzwerktreiber vergleicht, an dem ich jetzt schon Ewigkeiten hänge... :roll:).
Vielleicht ein kleines Statusupdate - wie weit bist du denn im Moment? Könntest du Hilfe von anderen gebrauchen (vorausgesetzt natürlich immer, irgendjemand interessiert sich dafür) oder soll ich den ncurses-Eintrag aus der Liste wieder entfernen?
-
Ich bin noch am "verstehen" des Codes, da das ganze doch recht komplex ist und ich nicht unbedingt so viel Zeit habe.
Die VI portierung danach ist wie ich das bis jetzt überblickt habe dann recht einfach, da nur die Datei mit der Abfrage eines Tastendrucks geändert werden muss.
Den Rest macht ja dann ncurses.
Aus meiner Sicht kannst du ncurses aus der Liste raus nehmen oder du schreibst meinen Name dahinter.
-
Weißt du ob das irgendwelche ungewollten Auswirkungen hat? Ich mein Ubuntu wird nicht zum Spaß dash einsetzten, oder?
Ubuntu möchte die Leute dazu zwingen, auch nach /bin/bash zu verlangen, wenn eine bash notwendig ist. Die dash ist eine Bourne-kompatible Shell und damit POSIX-kompatibel; aber viele Scripteschreiber benutzen bash-Features, ohne es zu wissen.
Das stört besonders die Nicht-Linuxe (*BSD), weil dort die bash eben nicht Standardshell ist, sondern csh und andere. Der "richtige" Weg ist, die Scripte anzupassen und auf bash zu verweisen.
Da aber fast alle Linux-Distributionen /bin/sh auf /bin/bash linken, kannst du das auch tun. Das ist dann ein "dirty hack", den alle machen (, und damit die Misere erst erschaffen haben). Du wirst jedenfalls keine ungewollten Auswirkungen haben.
-
Hi!
Ich hatte schonmal eine (äußerst, äußerst, ÄUßERST) simple Version eines Editors (wenn man das denn nennen konnte) geschrieben, allerdings war ich dann mit anderen Dingen und der Schule beschäftigt...
Da ich im Moment viel Zeit habe und sehr viel Lust dazu habe, an LOST mitzuwerkeln, würde ich gern bei den User-Programmen mithelfen.
Ich würde gern bei jemanden im Team mitprogrammieren, kann aber auch alleine etwas auf die Beine stellen ;)
Eine Idee wäre doch übrigens (was aber auch nur mit curses möglich wäre?), eine Art Midnight Commander (oder Norton Commander für alles DOSser ;)) zu schreiben. Desweiteren sind so viele kleinere Sachen eine Idee, wie ein Kalender oder einen erweiterten Taskmanager (wie top unter Unix).
Also, ich biete meine Hilfe gerne an!
-
Also ich hab ja schon im IRC geschrieben dass ich gerne mich an die Shell ranmache. Bin dabei, die Dateinameerweiterung zu implementieren (bzw. hab sie schon implementiert, muss aber Linux installieren um alles zu testen) sowie endlich die Pipes zu implementieren.
-
Ahoi Ahoi,
ich meine den code von ncurses jetzt soweit verstanden zu haben, damit ich mit der Portierung anfangen kann.
Ich habe mir grad ncurses 5.6 geholt und werde heute Abend damit beginnen, das zu portieren.
Wie ich das Compilieren muss und alles, werde ich noch herausfinden müssen, was allerdings kein Problem darstellen sollte.
Gruß Christian
-
Ich wuerde auch gerne meinen kleinen Teil zum Community-OS beitragen. Gibt es vlt schon irgendwelche Dokumente wie man Applikationen hinzufuegt/kompiliert. (Evtl ist auch eine API-Dokumentation vorhanden?)
-
Die API ist POSIX für normale Anwendungen. Eine Anwendung kommt meines Wissens nach in src/modules/c/<appdir>, schau dir am besten mal die anderen apps dadrin an, um herauszufinden was du buildtechnisch noch tun musst.
-
POSIX ist nicht unbedingt die native API für LOST, sondern mehr eine Art Kompatibilitätsschicht. In manchen Fällen ist es wahrscheinlich trotzdem das beste, POSIX-Funktionen zu verwenden, aber zum Beispiel Dinge wie Netzwerk sind alles andere als POSIX-artig. Als eine Art Dokumentation der API können die Headerdateien in src/modules/include herhalten.
Für neue Apps einfach das Verzeichnis anlegen und eine Makefile.all kopieren und anpassen.
Und ansonsten, den IRC-Channel kennst du ja. ;)
-
Nun da ich gestern erfahren habe, dass ncurses schon portiert sei, habe ich mir etwas anderes vorgenommen.
Und zwar habe ich hier ein paar alte Grafikkarten herumliegen und in Testrechnern verbaut. Da ich mich so oder so mit diesen beschäftigt hätte, kann ich auch Treiber dafür schreiben.
Die Frage ist jetzt nur, es hieß es gibt im CDI ein Grafik Subsystem. Gibt es dazu schon eine Dokumentation?
Des Weiteren habe ich noch eine andere Frage: Im Internet habe ich eine Datenbank gefunden, die besagt, dass z.B. die ATI Mach64 VT die ID 0x4654 hat. Wenn ich das dann so richtig verstanden habe, sind die IDs IDs von ATI Karten. Das würde heißen, dass andere Hersteller, die den gleichen Chip benutzen, aber andere IDs haben oder liege ich da falsch?
Gruß Christian
*EDIT*
Wie sieht es mit dem VBE/AF Standard aus?
Wäre es eventuell nicht besser Treiber nach diesem Standard zu schreiben?
-
Die Frage ist jetzt nur, es hieß es gibt im CDI ein Grafik Subsystem. Gibt es dazu schon eine Dokumentation?
Am besten mal im IRC phoenix oder janosch fragen, die haben die aktuelle Headerdatei.
Des Weiteren habe ich noch eine andere Frage: Im Internet habe ich eine Datenbank gefunden, die besagt, dass z.B. die ATI Mach64 VT die ID 0x4654 hat. Wenn ich das dann so richtig verstanden habe, sind die IDs IDs von ATI Karten. Das würde heißen, dass andere Hersteller, die den gleichen Chip benutzen, aber andere IDs haben oder liege ich da falsch?
PCI-Karten haben eine Vendor-ID und eine Device-ID. Was du hast, scheint die Device-ID zu sein, d.h. eine andere Karte eines anderen Herstellers könnte dieselbe ID haben. Erst wenn du noch die Vendor-ID von ATI dazunimmst, wird die Sache eindeutig.
*EDIT*
Wie sieht es mit dem VBE/AF Standard aus?
Wäre es eventuell nicht besser Treiber nach diesem Standard zu schreiben?
Welchen Vorteil hätte man davon?
-
Des Weiteren habe ich noch eine andere Frage: Im Internet habe ich eine Datenbank gefunden, die besagt, dass z.B. die ATI Mach64 VT die ID 0x4654 hat. Wenn ich das dann so richtig verstanden habe, sind die IDs IDs von ATI Karten. Das würde heißen, dass andere Hersteller, die den gleichen Chip benutzen, aber andere IDs haben oder liege ich da falsch?
PCI-Karten haben eine Vendor-ID und eine Device-ID. Was du hast, scheint die Device-ID zu sein, d.h. eine andere Karte eines anderen Herstellers könnte dieselbe ID haben. Erst wenn du noch die Vendor-ID von ATI dazunimmst, wird die Sache eindeutig.
Die Vendor-ID von ATI ist 0x1002. Dann wäre das geklärt.
*EDIT*
Wie sieht es mit dem VBE/AF Standard aus?
Wäre es eventuell nicht besser Treiber nach diesem Standard zu schreiben?
Welchen Vorteil hätte man davon?
Nun die Treiber wären zum einen nach dem festgelegten Standard und zum anderen kann man eben diese Treiber dann auch flexibler einsetzen (Windows, Linux), wenn ich mich jetzt nicht irre. :roll:
Zumindest meine ich, dass das so sinngemäß richtig übersetzt ist ;)
This document defines the interface for a new operating system portable, loadable device driver architecture that will provide access to accelerated graphics hardware.
-
Nun die Treiber wären zum einen nach dem festgelegten Standard und zum anderen kann man eben diese Treiber dann auch flexibler einsetzen (Windows, Linux), wenn ich mich jetzt nicht irre. :roll:
Zumindest meine ich, dass das so sinngemäß richtig übersetzt ist ;)
This document defines the interface for a new operating system portable, loadable device driver architecture that will provide access to accelerated graphics hardware.
Vergiss am besten den VBE/AF Standard :wink: Hast ja selbst im anderen Thread festgestellt, dass das ein wenig veraltet ist... Baut lieber in mit/innerhalb von CDI was sinnvolles eigenes. VBE/AF ist mit ziemlicher Sicherheit auch ein ABI-Standard und das macht es imho schonmal total unbrauchbar.
-
Nun die Treiber wären zum einen nach dem festgelegten Standard und zum anderen kann man eben diese Treiber dann auch flexibler einsetzen (Windows, Linux), wenn ich mich jetzt nicht irre. :roll:
Zumindest meine ich, dass das so sinngemäß richtig übersetzt ist ;)
This document defines the interface for a new operating system portable, loadable device driver architecture that will provide access to accelerated graphics hardware.
Vergiss am besten den VBE/AF Standard :wink: Hast ja selbst im anderen Thread festgestellt, dass das ein wenig veraltet ist... Baut lieber in mit/innerhalb von CDI was sinnvolles eigenes. VBE/AF ist mit ziemlicher Sicherheit auch ein ABI-Standard und das macht es imho schonmal total unbrauchbar.
Ich werde mich beugen. :-P
Allerdings werde ich den Standard etwas genauer unter die Lupe nehmen, da er ja nur einen gewissen Funktionsumfang definiert.
-
Ich werde mich beugen. :-P
Ich habe keine normative Macht, va. nicht bei LOST :wink: und va. letzteres ist natürlich auch gut so :-P