Nachrichten

81

Offtopic / Re: iPod touch mit Linux?

« am: 07. November 2011, 19:57 »

Ne, das heißt ich hab natürlich selber mal irgentwas gefunden, weiß aber nicht mehr wo, und habs jetzt auf die Schnelle auch nicht wieder gefunden.

82

Offtopic / Re: iPod touch mit Linux?

« am: 07. November 2011, 19:49 »

Schau mal im Internet, ich glaub da gibt's irgentwie so was.

83

Offtopic / Re: Rückgabe von 128bit Datentypen

« am: 06. November 2011, 21:52 »

ich hatte eine durch einen Pointer (Rueckgabe in eax) beschriebene Stelle im Speicher in Augen. (Wofuer 16 byte in der Runtime-lib Reserviert sind.

Das geht auf jeden Fall in die Hose, wenn der Platz in der Runtime-Lib nur ein einziges mal vorhanden ist dann ist Dein Programm nicht multithreading tauglich. Wenn Du anderen Speicher benutzen möchtest dann benötigst Du im Endeffekt eine Art malloc (was der Callee aufruft) ein ein free (was der Caller aufruft). Das der Callee dem Caller einen Pointer gibt wo er das Ergebnis hingelegt hat führt IMHO grundsätzlich zu unlösbaren oder überteuerten Problemen.

Das mit dem Multitasking hab ich nicht bedacht, danke für den Hinweis. Ich möchte eigentlich vermeiden, dass man für jede Rückgabe von (abgesehen von ganz einfachen Datentypen) malloc() und free() aufrufen muss.

Ich hatte eigentlich an eine andere Idee im Sinn.

Dann erzähl doch mal. Das was Du da geschrieben hast klingt auf jeden Fall nicht nach einer Methode die von C oder C++ oder einer anderen üblichen Programmiersprache unterstützt wird. Ein Compiler-Feature das man nur nutzen kann wenn man in Assembler programmiert nützt auch nichts da man dafür ja keine Hochsprache benötigt. Für welche Programmiersprache willst Du überhaupt einen Compiler bauen?

Im Default-Fall wird ecx unbestimmt von einer Funktion zuruekgeeben.

Trotzdem ist ein Register weg das man auch sinnvoll nutzen könnte. Das entspricht auf jeden Fall nicht der Philosophie das Features die nicht benutzt werden auch nix kosten dürfen.

Was für eine Fehlerbehandlung schlägst du den vor? ecx wird bei den gängigen Konventionen auch unbestimmt zurückgegeben. (D.h. es kann in der Subroutine nach belieben verwendet werden, und brauch nicht auf irgendeinen Finalwert gebracht werden.

P.S Ich plane eine Compiler für eine eigene Sprache (Aurora), warscheinlich auf LLVM oder i386-Assembler Basis.

Im Fehlerfall muss die Funktion die Ruecksprungaddresse mit 0 ueberschreiben

Aha, und wo führt dann das RET hin?
Entschuldige Bitte die direkte Frage aber ein erfahrener Assembler-Programmierer bist du nicht gerade oder?

Das hab ich schon bedacht, dass man die Rücksprungadresse vorher sichern und manuell anspringen muss.

Einen Fehler zurück zu melden den der Caller nach belieben ignorieren darf ist auf jeden Fall keine strukturierte Vorgehensweise, der Callee meldet den Fehler doch nicht ohne Grund und wahrscheinlich sind die normalen Rückgabewerte dann auch unbrauchbar (schließlich signalisiert ein Fehler doch für gewöhnlich das die Funkion nicht korrekt bis zum regulären Ende durchlaufen konnte).

Wahrscheinlich lass ich die betroffenen Register mit irgendeinem Standartwert z.B. "0" füllen. (Oder der edx mit der Rücksprungadresse (auch bei int64), was die Fehlerrückkehrroutine vereinfachen würde.)

84

Offtopic / Re: Rückgabe von 128bit Datentypen

« am: 06. November 2011, 15:02 »

Naja, mir ist grad aufgefallen, das das mit der Stackuebergabe gar nicht in meinem Konzept stand, ich hatte eine durch einen Pointer (Rueckgabe in eax) beschriebene Stelle im Speicher in Augen. (Wofuer 16 byte in der Runtime-lib Reserviert sind.

Zu der Sache mit der Fehlerrueckgabe, da ich mich mit C++ nicht wirklich auskenne, hab ich keine Ahnung was SW-Exeptions sind. Ich hatte eigentlich an eine andere Idee im Sinn. Im Default-Fall wird ecx unbestimmt von einer Funktion zuruekgeeben. Im Fehlerfall muss die Funktion die Ruecksprungaddresse mit 0 ueberschreiben und den Fehlerwert in ecx zurueckgeben. (eax & co. sollten trozdem irgenteinen mehr oder weniger Sinnvollen Inhalt enthalten.) Das ist zwar ein bisschen aufwaendig, aber es ist nur im Fehlerfall noetig. Wenn der Caller den Fehler nicht versteht, oder ignoriert, ist das nicht schlimm, weil er dann ecx ignuriert und nur eax & co. beachtet.

85

Offtopic / Re: Rückgabe von 128bit Datentypen

« am: 01. November 2011, 18:46 »

Naja, bei OS-def, Eigenen Programm Strukturen oder bei jeglichen Runtime Lib Krempel kann man in der Tat, die Aufrufkonvention über den Haufen werfen, da diese eh nur intern verwendet werden, aber extern ist zumindest optional eine gescheite C Kompatibilität (cdecl), wenn nicht sogar eine Kompatibilität mit stdcall und der C++-namespace/Overload Convention sinnvoll, sonst wird's schwer, irgendwelche externen Bibliotheken zu nutzten.

Zu der Sache mit dem 128 bit Integer und Quad Float. Ich habe mich entschlossen (zumindest auf dem x86-32), beide Datentypen auf dem Stack zugeben (auf [esp] nach Rückkehr von der Unterfunktion) über den Stack zurück zu geben, wobei der entsprechende Speicherplatz zuvor von der Aufrufenden Funktion reserviert werden muss (Wer den Restlichen Stack freigibt, entscheidet die Aufrufende Funktion. Beide Datentypen sind ohnehin ehr als Puffer für die Zukunft gedacht und weniger zum Produktiven Einsatz, (besonders bei dem 128 bit Integer).

86

Offtopic / Rückgabe von 128bit Datentypen

« am: 30. October 2011, 17:39 »

Da ich ja bekanntlich kein OS sonder einen Compiler plane hab ich mir schon mal über alle Möglichen Dingen Gedanken gemacht. Ein Aspect sind ist die Rückgabe von 128 bit Daten (die mit int128 und Gleitkommazahlen vierfacher Genauigkeit unterstützt werden sollen.)

Bei der Rückgabe solcher Zahlen von Funktionen gibt es folgende Ansprüche
- ecx ist für die Fehlerrückgabe reserviert und mussfreigehalten werden
- Die xmm Register werden nicht Vorrausgesetzt.

Es gibt folgende Möglichkeiten:

edi:esi:edx:eax
        Vorteil: Logische Erweiterung zu 64 bit
   Nachteil: Verletzung der "Nur eax, ecx, edx und der Gleitkomma dürfen verändert werden"-Regel.

st(1):st(0) {64 bit Integer lassen sich sicher in Gleitkommaregister laden.}
   Vorteil: Die Register bleiben frei.
   Nachteil: Daten können quasi nur direkt in den Speicher kopiert werden.

Speicherstelle mit Pointer in eax
   Vorteil: Die Register bleiben frei, Kompatibel zur Übergabe von structs
   Nachteil: Es muss zuerst eine geeignete Speicherstelle reserviert werden.

Ich wollt mal fragen, was ihr da für das beste haltet.

87

OS-Design / Re:neues OS-Konzept

« am: 23. August 2011, 17:16 »

Die genannten Funktionswünsche scheinen sich nicht an den Kernel sondern ehr an irgendwelche Infrastrukturen, wie beispielsweise das GUI zu richten. Da ich dein Konzept interessant finde, aber leider nicht wirklich durchblicke kann ich das leider nicht einwandfrei beurteilen.

Solange du keine Anforderungen stellst, die nicht auch ein bisheriger Kernel lösen kann, schlage ich dir auf einen bereits existierenden Kernel aufzubauen.

88

Softwareentwicklung / Re:Was ist schwerer Compilerbau oder OS dev?

« am: 20. July 2011, 17:13 »

Was ich persönlich denke, ist, das die Arbeit an einem Betriebssystem zwar anspruchsvoll, aber eigentlich nicht unglaublich abstrakt und schwer ist. Das Problem liegt er im Umfang. Man muss sich einfach mit unglaublich vielen unterschiedlichen Dingen beschäftigen muss, damit das System etwas drauf hat.

Compilerbau ist etwas anderes. Ein Compiler besteht aus mehren übereinandergelegten Automaten. Die nacheinander den Quelltext oder Stücke davon bearbeiten und an den nächsten weitergeben. Ich persönlich habe bereits die scheinbar einfache Aufgabe, eine Compiler der 5 Funktionen + einen Datentyp vordefinierter Variablen beherrscht als schon ziemlich schwierig empfunden (mittlerweile nehme ich für so was Lua). Andererseits ist die Arbeit überschaubarer.

Also ich denke, es ist beides in etwa gleich schwer. Entscheidend ist dabei aber auch das persönliche Interesse bzw. die Begabung für das eine oder andere. Momentan scheint man mit OS-Dev jedoch besser bedient was Quellen anbelangt (lowlevel, osdev.org, osdever.net usw.), als ich mich mal etwas nach dem Thema Compiler umgesehen habe, konnte ich nicht allzu viel finden.

Da muss ich dir recht geben, warum weiß ich auch nicht. Vermutlich gibt es mehr Hobbyprogrammier, die ein OS programmieren wollen (ich denk mal das "Ich will so sein wie Linus Torwals" spielt bei manchen 'ne Rolle.)

Ich finde auch, dass man bei einem OS schneller einen Einblick bekommt, wenn man den Source eines "großen" OS durchsieht. Mich etwas im Linux-Kernel umzusehen fiel mir deutlich leichter als den Code des FreeBASIC-Compilers zu kapieren.

Naja, ich denk mal Linux wird ja von sehr vielen Leuten bearbeitet, und muss deshalb auch logisch aufgebaut werden, während FreeBasic erst mal nur von ein paar Leuten entwickelt wurde, die sich erst mal wenig um die Quellcode-Verzeichnis-Struktur gekümmert haben.

Letztendlich sehe ich aber keine wirkliche Relevanz hinter der Frage. Entscheidend, ob man sich mit dem einen oder anderen beschäftigt, sollte vor allem das persönliche Interesse sein. Wobei ich allerdings davon abrate, sich mit beidem zur gleichen Zeit zu beschäftigen

Da hast du recht. Deshalb hab ich mein OS-Projekt beerdigt. (War eh nix außer eine kprintf() Function in FB.)

89

Softwareentwicklung / Re:Was ist schwerer Compilerbau oder OS dev?

« am: 17. July 2011, 17:12 »

Naja, das resultiert aus dem Paging, bei dem die Segmentierung eh nur stört, so ähnlich wie heute jeder lieber PM stadt RM benutzt.

90

OS-Design / Re:Sicherheitskonzept VFS/Aufbau Wurzelverzeichnis "/"

« am: 16. July 2011, 22:03 »

Das ist eine gaaanz schlechte Idee.

Ich möchte in meinen Quelltexten ein "#include <SDL.h>" machen und dann die aktuelle SDL-Version benutzen und nicht bei jeder neuen (100% kompatiblen) SDL-Version meine Sourcen anpassen müssen. Das wäre Ärger zur Compilezeit. Zur Laufzeit würdest du also immer gegen eine fixe Lib-Version linken, was Library-Updates unmöglich macht. Wenn du stattdessen ein "nimm die aktuellste Version der Lib" möchtest, dann muss dein Runtime-Loader trotzdem /ear/lib/* traversieren und ziemlich viel Stringmatching machen.

Eine Möglichkeit wäre, in /ear/lib/* nur Symlinks auf die jeweils aktuellsten Versionen zu haben, die dann in /ear/lib/libs/libname-version/libname-version.so liegen. Aber dann kannst du die auch gleich das Unixprinzip "/ear/lib/libname.so -> /ear/lib/libname.so.version" benutzen...

Wieso. Es ist dir doch egal ob die Headerdatei SDL.h die Bibliothek /ear/lib/SDL.so oder /ear/lib/SDL-3.5.6/bin/SDL.so (Version ist jetzt zufällig) anfordert (das steht ja im Header). Und die Headerdatei findest du ja nicht irgendwo sondern in /ear/include/c/. Wenn du eine explizit ältere Version von SDL benutzen willst musst du halt z.B. /ear/include/c/version/SDL-3.4.2.h" benutzen. Die aktuelle Version ist als Symlink auf die aktuelle gestaltet.

Alles in Allem Danke ich dir aber für deine konstruktive Kritik. Ich versuche halt nur, das Ein-Programm = Ein-Ordner-System (welches ich persönlich bevorzuge) mit den Ansprüchen, die bei Linux vorherrschen (Gemeinsame Bibliotheken, Einfache Nutzung über's Shell, etc.) zu verbinden.

Das geht einfach nicht, weil es zwei völlig unterschiedliche Paradigmen sind. Der einzige Ansatz, den ich da habe wäre eine doppelte Verwaltung: Also Programme werden in ihren eigenen Ordner nach /apps/appname/* installiert, aber installieren Symlinks nach /usr/bin, Manpages nach /usr/share/man, Konfigurationen nach /etc, ...). Wenn man regelmäßig nach toten Symlinks sucht, wird man die Reste auch wieder zuverlässig los.

Das halte ich für eine gute Idee (deinen Vorschlag)

Schwierig. Ich bin dafür, /usr unter Linux abzuschaffen, weil es keine besondere Bedeutung mehr hat. Ursprünglich galt ja, dass / nicht von der Paketverwaltung verwaltet wird (Basissystem), /usr hingegen schon und /usr/local wieder nicht. Inzwischen werden / und /usr beide verwaltet, ein shared-usr ist mit heutigen Distributionen nur noch schwierig (Xorg legt die Standardkonfig unter /usr/share/X11 ab, noch geht aber /etc/X11!) und die Vorteile nutzt nahezu niemand mehr.

Naja, ich find eine Trennung zwischen Systemtools (/bin) und root-Systemtools (/sbin), die beim Start vorhanden sein müssen, sowie "normalen" Programmen (/usr/bin) schon sinvoll. Wobei dir entgegen kommt, das es /usr in der FHL nicht gibt.

Ansonsten hast du recht. Wenn man erst bei der GDT ist, braucht man sich über das Datensystem keine Gedanken machen.

91

Softwareentwicklung / Re:Was ist schwerer Compilerbau oder OS dev?

« am: 16. July 2011, 20:22 »

Naja, anderseits ist es ja bewiesen, das sich in der Computerindustrie das durchsetzt, was einfach mehr oder weniger funktioniert, als das was ausführlichst philosophiert wurde. Bespiele gibt's genug: DOS (und später Win) über verschiedene andere, Linux über GNU Hurd, x86 Erweiterungen über neuere Architekturen.

92

Softwareentwicklung / Was ist schwerer Compilerbau oder OS dev?

« am: 15. July 2011, 20:28 »

Ich hab mich in letzter Zeit gefragt, was eigentlich schwieriger ist, eine Compiler zu bauen, oder ein Betriebssystem zu entwickeln.

Mir persönlich kommt Compilerbau sogar noch schwieriger vor, was sagt ihr dazu?

93

OS-Design / Re:Sicherheitskonzept VFS/Aufbau Wurzelverzeichnis "/"

« am: 15. July 2011, 20:23 »

1. Es gibt keine Möglichkeit Programme außerhalb von Respos vernünftig dem apt-system zuzufügen.

Doch, und zwar der gesamte Baum unterhalb von /usr/local (der unterliegt nicht der Paketverwaltung). Beispielsweise liegt /usr/local/bin in $PATH und /usr/local/lib wird ebenfalls beachtet.

Ich hab nicht behauptet, das man nicht auch Programme selber installieren kann. Dazu ist /usr/local und /opt ja da. Was ich kritisiert habe, das man das an apt vorbeimachen muss. (Ich stell mir ne Methode vor, bei der man eine Metadatei an apt übergibt, das dann unter zuhilfenahme der in der Respo und der in der Metadatei enthaltenen Pakete das Programm samt allen Abhängigkeiten installiert.)

3. Programme speichern ihre Benutzerdaten direkt in das ~ - Verzeichniss, was dazu führt, das dieser in Speicherdialogen (die versteckte Daten anzeigen) überquillt.

Richtig, allerdings wird mit ~/.local und ~/.config versucht, da wieder ein bisschen Übersicht reinzubringen.

Schön wär's. Leider liegt bei mir  immer noch von scheinbar jedem Programm ein Unterordner direkt im Homeverzeichniss.

Ansonsten habe ich an deinem System zu bemängeln, dass die Suche nach z.B. einer Lib dazu führt, dass sämtliche Verzeichnisse unterhalb von /ear/lib/* vom Loader durchsucht werden müssen und dass es prinzipiell mehrere gleichnahmige Dateien geben kann.

Wieso ich hab doch deshalb extra diese <name>-<version> Form eingeführt. Der Libname sollte halt in den Include-Header Dateinen gescheit vermerkt werden.

Wenn du /ear/proc/ als "eigene Dateien" betrachtest, verkennst du, dass dieser Ordner irgendwo unter /home liegen sollte - weil er nutzerspezifisch ist.

Da hab ich mich vertippt. Ich meinte C:/Programme nicht ./Eigene Dateien.

Alles in Allem Danke ich dir aber für deine konstruktive Kritik. Ich versuche halt nur, das Ein-Programm = Ein-Ordner-System (welches ich persönlich bevorzuge) mit den Ansprüchen, die bei Linux vorherrschen (Gemeinsame Bibliotheken, Einfache Nutzung über's Shell, etc.) zu verbinden.

Deine letzte Bemerkung halte ich für nützlich. Vielleicht ist es besser /usr doch nicht abzuschaffen und dafür die zusätzlichen Ordner /app mit den Unterverzeichnissen. /app/proc für proc für Programme und /app/run für die Executivdeskriptoren einzuführen.

94

OS-Design / Re:Sicherheitskonzept VFS/Aufbau Wurzelverzeichnis "/"

« am: 15. July 2011, 15:40 »

Ich prsönich finde, das auch das aktuelle Linuxsystem (dpkg/apt-basierende Ditros) gut, allerdings bemängle ich:
1. Es gibt keine Möglichkeit Programme außerhalb von Respos vernünftig dem apt-system zuzufügen.
2. dpkg verteilt die Packete munter über die Programmordner
3. Programme speichern ihre Benutzerdaten direkt in das ~ - Verzeichniss, was dazu führt, das dieser in Speicherdialogen (die versteckte Daten anzeigen) überquillt.

Also ich präfferiere folgendes System:

Das Grunddatensysstem entspricht dem von FHS, mit folgenden Erweiterungen. Inerhalb jedes Benutzerordners gibt es das Unterverzeichnis, ~/appdata welches die Programmdaten enthält. Auch gibt es einen Ordner /dae, welcher alle Server und Daemonen enthält, die notwendig sind, ein mikrokernelbasierendes System in Stand zu halten. Statt es /usr - Verzeichniss gibt es das neue /ear (Extended Application Reecurces) Verzeichniss ersetzt. Diese enthält die Ordner:
/ear/run/bin - Enthält kleine ein-Datei-Programme die nicht in /bin oder /sbin passen
/ear/run - Executionsdescriptor (Datei, die ihren Aufruf an das eigentliche Programm weiterleitet.)
/ear/proc - Enthält die Programmdaten (Fungiert so ähnlich wie eigene Dateien unter Win)
/ear/games - Optional, selbe wie /ear/proc, aber für Spiele.
/ear/lib - Programmunabhängige Bibliotheken, die nicht in /lib oder /ear/proc passen
/ear/inc - Programmheader zu den Bibliotheken. (in Unterordnern nach Programmiersprache.)
/ear/local - Programme die ohne Hilfe der Packetverwaltung installiert worden sind.
/ear/local/old
/ear/etc - Sonstiges

/ear/proc und /ear/lib bestehen hierbei aus Unterordnern. Diese folgen dem Schema <name>-<version>. Innerhalb dieser Ordner ist eine Struktur vorgegeben (alle Ordern optional):
./bin - Selbst ausführbare Dateien. (Also nicht bei Bibliotheken)
./share - Lizenztexte und co. (Geläufige Lizenzen können auch als Symlink auf /ear/etc/licences/<name> eingebunden sein.)
./src - Quellcode
Es dürfen auch noch weitere Dateien und Unterordner vorhanden sein.

Wie genau die Executionsdescriptoren in /ear/run umgesetzt werden, ist noch nicht genau festgelegt. Möglich wären Symlinks, Shellscripts (im schlimmsten Fall) oder auch Logdateien, wobei man hierfür Systemunterstürzung bräuchte.

95

OS-Design / Re:Sicherheitskonzept VFS/Aufbau Wurzelverzeichnis "/"

« am: 13. July 2011, 22:11 »

Naja, es gibt schon Situationen wo ein Leseverbot sinvoll ist. z.b. soll nur der root die Dateien lesen können, welche das Passwort enthalten. Wenn du ein echtes Netzwerk aufbaust, braucht auch nicht jeder alle Dateien lesen zu können.

96

OS-Design / Re:Schnellste Möglichkeit des Syscalls

« am: 12. July 2011, 15:10 »

Ok dann frag ich mal was anderes. Ist sysenter immer noch schnelle, wenn man dazu eine Funktion von der Syscall-Page aufrufen muss, als wenn man über eine Call-Gate arbeitet (dann ohne syscall-Page)

97

OS-Design / Re:Schnellste Möglichkeit des Syscalls

« am: 11. July 2011, 22:08 »

Und ist das mit der Call Gate schneller als sysenter?

PS: Das mit dem far call ist logisch, sonst könnt man ja den Code als Inhalt der R3-segments laden und dann mit einem far call als r0 code anspringen.

98

OS-Design / Re:Schnellste Möglichkeit des Syscalls

« am: 11. July 2011, 21:53 »

Nochmal zurück zum far call. Wenn ich in der GDT das Ring 3 Segment über das Ring 0 Segment lege, kann ich doch mit einem far call auf das Ring 0 Segment wechseln und mit far ret wieder zurückkehren.

99

OS-Design / Re:Schnellste Möglichkeit des Syscalls

« am: 11. July 2011, 20:32 »

und das klappt? ich dachte immer da muss man zwischen intel und amd unterscheiden.

100

OS-Design / Re:Schnellste Möglichkeit des Syscalls

« am: 11. July 2011, 20:18 »

Ah danke jetzt kapier ich das. Was mich verwirrt ist, das man in Linux Assemblerprogrammen Syscalls über Interrupts handelt. Besitzt das System dann zwei Syscallmethoden?

Gruß Sannaj