Betriebssystem
-
booten würd ich grundsätzlich erstmal per grub machen,
auf anderen architekturen dann entweder grub2 oder per openfirmware
auf einigen arm's gibts komische bootumgebungen, die wären dann haariger
da es ein microkernel ist, halte ich es generell für sinnvoll früher oder später ein posix api service bereitzustellen
auf real mode zeugs würde ich wenn möglich vollständig verzichten
*edit* fixed typo
-
r0nny schrieb:
auf einigen arm's gibts komische ootumgebungen, die wären dann haariger
was sind ootumgebungen?
-
Hat grub einen Dynamischen Linker an Bord? Wenn nicht, dann is er leider maximal zum Laden des Second Stage geeignet.
Außerdem möchte ich mich, da ich immer noch alleine bin, auf x86 und vielleicht dann später auf x86_64 beschränken.
Wieso grad bei einem Microkernel eine POSIX-API? Nur, damit grub geht?
Real Mode braucht man nur, wenn grub das nicht übernehmen kann.
Es existiert schon ein Bootsector, der eine statische ELF-exe läd - derzeit noch von Floppy, später dann aber von Disk. D.h., dass man wenig umschreiben muss.
-
grub hat keinen dynamsichen linker an board, packt einen aber direkt in den 32 bit mode, und kann bereits service-module pre-loaden
die grundlegenden dienste, die dynamisches laden usw bereitstellen sollten sowiso statisch in sich gelinkt sein, und des rest sollte einfach per fork von einem basisprozess der nur den dynamischen linker enthält (und alles weitere hinzulädt) erledigt werden
*edit*
posix api soll nicht im kernel sein, sondern als dienst angeboten werden, da einfach viele tools dann einfach portierbar sind, und bestimmte programmiersprachen posix als gundlage benötigen
-
In den Protected Mode komme ich schon selbst. Das ist nicht schwer. Dass grub Module laden kann, weiß ich. Aber ich weiß zum Zeitpunkt, an dem grub läuft, ja nicht, welche Bibliotheken der Kernel dann braucht.
Wieso man POSIX als Dienst anbieten soll, ist mit nicht ganz klar. Es ist nur eine API. Eine Bibliothek sollte dafür reichen. Aber wie gesagt, ich möchte kein POSIX ebenso wenig Programmiersprachen, die das voraussetzen, wobei mir nicht ganz klar ist, welche Sprache von POSIX abhängt.
Ich möchte die Tools selbst schreiben. Für einen Router braucht man ja keinen Compiler. Programme, wie die der coreutils sind schnell geschrieben.
Wie schon davor im Thread gesagt wurde: Wenn man POSIX will, kann man ja existierende Betriebssysteme verwenden. Mir ist klar, dass POSIX verlockend ist, weil man dann die GNU Programme drauf laufen lassen kann. Aber ich möchte das maximal beim gcc machen. Der Teil der POSIX API, den der gcc verwendet, ist eh noch der einfacher aber z.B. die POSIX-Threads möchte ich echt nicht nachbauen müssen.
-
os_programmierer schrieb:
Wieso man POSIX als Dienst anbieten soll, ist mit nicht ganz klar. Es ist nur eine API. Eine Bibliothek sollte dafür reichen.
Auch fuer so obskure Dinge wie Signal Handling?
-
Gute Frage...
Man könnte Signale in Messages verpacken. Beim Start einer POSIX-Anwendung wird ein separater Thread erstellt, der dann auf solche Messages wartet und die Handler aufruft. Dazu muss man nur die IPC API des OS in die der POSIX-Signale umwandeln. Der Aufruf von kill(2) erzeugt für das angegebene Signal eine Message, schaut nach, ob der Prozess mit der angegeben ID auch ein POSIX-Prozess ist (Das kann man leicht, indem man testet, ob der Zielprozess einen Signal-Handler-Thread hat.) und schickt ihm dann die Nachricht. Sollte der Zielprozess keinen Signal-Handler-Thread haben, ist es kein POSIX-Prozess und kill gibt dann ESRCH zurück. Ich denke, das wäre eine gute Lösung. Möglich wäre auch eine Lösung ohne separatem Thread. Es wird einfach eine Message Queue z.B. mit Namen "/posix/signals" erzeugt und sobald eine Message dort eintrifft, wird ein Handler aufgerufen, der dann den mit signal(2) bestimmten handler aufruft.Die ganze POSIX-API könnte man leicht in einer libposix unterbringen btw. Aber wie gesagt, mir wäre die native API lieber. Wenn ich sich aber jemand meldet, der die libposix schreiben will, bin ich klarerweise gerne bereit, denjenigen auch zu unterstützen.
-
das ist technisch nicht möglich, da posix signale eine art programminterupt sind
der laufende main-thread wird unterbrochen und es wird einiges mit seinem stack angefangen
*edit*
man mönte des aber recht toll auf eine art "urgent messaging" system abbilden, das sicherstellt, das bestimmte nachrichten wie speicherzugriffsfehler, oder termination so schnell wie möglich behandelt werden
*edit 2*
wenn man das system ähnlich den posix signalen gestaltet, kann man das ganze sogar recht einfach 1:1 abbilden
-
r0nny schrieb:
das ist technisch nicht möglich, da posix signale eine art programminterupt sind
hmm Naja... Das Eintreffen einer Message kann genau das gleiche tun.
r0nny schrieb:
der laufende main-thread wird unterbrochen und es wird einiges mit seinem stack angefangen
Was wird denn mit dem Stack angefangen?
Die Message muss ja nicht urgend sein. In meinem Beitrag davor hab ich gemeint, dass man eine Message Queue einrichtet, die nur auf solche POSIX-Signal-Messages hört. Dazu wird ein Handler für das Eintreffen eines Signals installiert, der dann - das ist nicht so genau in meinem Beitrag herausgekommen - den Main-Thread unterbricht. Dieser Handler erkennt die Art des Signals und tut dann entsprechendes (Programm abwürgen, signal(2)-Handler starten, ...). Signale wie SEGFAULT oder SIGILL oder andere kommen vom Kernel. Dazu muss es im OS sowieso eine eigene API geben. Wenn man diese "Signale" vom OS dann per nativer API abfängt, kann man immer noch die POSIX-Handler aufrufen.
r0nny schrieb:
wenn man das system ähnlich den posix signalen gestaltet, kann man das ganze sogar recht einfach 1:1 abbilden
Signale sind nichts anderes als Messages. Nur meistens ohne Inhalt. Allein das Eintreffen einer solchen "Message" ist schon Signal genug.
-
posix signale sind nicht blos nachrichten, sie bewirken einen sofortigen funktionsaufruf im hauptthread des zielprozesses
*edit*
wenn normales message-processing einem interupt gleich wird, wird das programm mit sicherheit überaus langsam
-
Ich frag' mich gerade, welche Plattform es sein soll.
Für X'86 ists irgendwie zu langweilig, weil das Sterben an der Vorlage Anderer nahezu "vorprogrammiert" ist
. Linux/FreeBSD muß nicht neu erfunden werden, OS/2 ist tot und BeOS heißt zwar mittlerweile anders, erntet aber die gleiche "Begeisterung".Und C++ als Basis, tjaa, kann man wahrscheinlich schon machen, aber was willste damit außer Lernen?
Vor allem: Was soll das OS können? Man legt mit einer bestimmten Zielsetzung los und die ist noch nichtmal klar: Multiuser / Multitasking naja - Realtimefähigkeiten schon kniffeliger.
Auf jeden Fall solltest Du einen stringenten Ansatz vorbereiten und wenn den ein paar Leute gut finden, gibt's auch ein Team
-
pointercrash() schrieb:
klar: Multiuser / Multitasking naja - Realtimefähigkeiten schon kniffeliger.
gute idee. mach' doch 'ne realtime-erweiterung für windows.
soweit ich weiss, gibt's in der hinsicht noch nix freies.
-
pale dog schrieb:
gute idee. mach' doch 'ne realtime-erweiterung für windows.
soweit ich weiss, gibt's in der hinsicht noch nix freies.
Eigentlich dachte ich eher an ein Kuchenblech mit 20 ARMs oder SH8 drauf, aber ja, für Win gibt's tatsächlich nichts Gescheites an RT- Extension.
-
os_programmierer schrieb:
r0nny schrieb:
der laufende main-thread wird unterbrochen und es wird einiges mit seinem stack angefangen
Was wird denn mit dem Stack angefangen?
NAME sigaltstack - set and/or get signal stack context SYNOPSIS #include <signal.h> int sigaltstack(const stack_t *ss, stack_t *oss); CONFORMING TO SUSv2, SVr4, POSIX.1-2001.
-
Um ehrlich zu sein, möchte ich mich nicht unbedingt damit aufhalten, wie man am besten POSIX-Signale implementiert. Wenn ihr ein POSIX-OS haben wollt oder eine API dazu, dann verwendet halt ein Unix. Ich möchte aber keine POSIX-API. Das ist eine feste Voraussetzung. Sorry. (@pointercrash(): stringent :-))
@pointercrash()
Ich hab als erstes Einsatzgebiet einen Router genannt. Reicht das nicht? Das wird viel Arbeit.
Der Sprung von x86er zu x86_64 ist nicht so enorm groß. Außerdem besitze ich keinen 64bit Prozessor. Und ein OS nur auf Basis eines Emulators zu schreiben, ist sicher mühsam. Man sollte es schon immer wieder dann auf einer richtigen Maschine ausprobieren.
Der stringente Ansatz ist da. Multiuser und Multitasking sind sowieso klar. Zusätze zu Linux, wie KVM, PAX, grsec usw., sollten direkt im OS vorhanden sein. Wie gesagt, ich möchte jetz nicht ein komplett anderes OS. Ich bin für eine so breite Basis, dass man das OS dann leicht auf verschiedene Architekturen portieren kann und auch verschiedene Anwendungszwecke zusäzlich einbauen kann (Realtime, Shared-Memory-Cluster, ...). Bevor eine Basis existiert, bringt es wenig, sich auf so hochgestecke Ziele einzuschwören. Ich möchte auf keinen Fall ein OS, das dann niemand verwenden kann bzw. das nur für kleine Nischenbereiche verwendbar ist. Wichtig sind noch die Dogmen:
- ein Paket für einen Zweck
- alle Pakete werden so gut es geht getestet
- ein standardisiertes Versionsmanagment
- möglichst keine externen Patches (Funktionen sollten eher in die Pakete eingebaut werden als Plugins z.B.)
- Sicherheitsfunktionen wie grsec, selinux, PAX
- EINE öffentliche Distribution mit einem Paketmanagment mit Signaturen für die Pakete
- zusätzlich für lokale Netzwerke eine angepasste Distribution zur Administration z.B. mehrere Router
- Pakete werden nur in die Distribution aufgenommen, wenn sie den Standards entsprechen. D.h. vor allem, dass sie zuerst die existierende API verwenden und erst dann eigener Code entwickelt wird.
Ich erwarte mir dadurch Vorteile bei der Sicherheit, Stabilität, Usability und dem Ressourcenverbrauch (Trotz immer performanterer Hardware, sollte Effizienz immer noch ein wichtiger Teil beim Softwaredesign sein, wenn auch nicht so wichtig wie die ersten drei genannten Designziele.) des ganzen OS inklusive der Pakete.
Ich hoffe, dass diese Ziele gut genug sind. Mir sind sie sehr wichtig. Ich erwarte keines Falls, dass das OS Konkurrenz zu einem existierenden wird.@Mr. N
Auf meinem Gentoo finde ich in signal.h keine signalstack Funktion. Im glibc Funktionsindex existiert die Funktion auch nicht auch in keiner anderen Datei unter /usr/include. Wenn die glibc diese funktion nicht unterstützt, so wird es im neuen OS wohl auch nicht so wichtig sein. Ich habe die man page der Funktion auf opengroup gefunden und gelesen. Man könnte möglicherweise über die Thread-API die Funktionalität in das OS einbauen, wobei ich mir nicht wirklich sicher bin, ob das so klug und portable ist, mit dem Stack herumzuspielen. Welches OS verwendest du?
-
os_programmierer schrieb:
@Mr. N
Auf meinem Gentoo finde ich in signal.h keine signalstack Funktion.Ich verwende Ubuntu 7.04 und die Funktion sigaltstack (NICHT signalstack) existiert.
-
OK. Hab mich da bei der Suche in /usr/include vertippt. Bei der Suche auf google hab ich das Wort wohl kopiert... Aber ich kann nur wiederholen, dass man auch das sicher irgendwie mit der nativen API emulieren kann. Wobei ich ebenso noch immer gegen solche Funktionen und im Gesamten gegen POSIX bin. Mir ist echt nicht klar, wieso ihr unbedingt POSIX wollt.
-
os_programmierer schrieb:
OK. Hab mich da bei der Suche in /usr/include vertippt. Bei der Suche auf google hab ich das Wort wohl kopiert... Aber ich kann nur wiederholen, dass man auch das sicher irgendwie mit der nativen API emulieren kann. Wobei ich ebenso noch immer gegen solche Funktionen und im Gesamten gegen POSIX bin. Mir ist echt nicht klar, wieso ihr unbedingt POSIX wollt.
Ich will kein POSIX, ich glaube nur nicht, dass man das eben mal schnell als Programmbibliothek hacken kann.
-
Vielleicht gibt es manche Funktionen, bei denen das sehr schwer bzw. unmöglich ist. Zu bedenken ist, dass die glibc POSIX auch nur als Bibliothek implementiert. Nicht alles hat/braucht sofort Kernel Support.
Ich will die Diskussion um POSIX nicht abwürgen, aber vielleicht könnte man sie auf einen Zeitpunkt vertagen, zu dem man mehr über das OS als solches und die native API diskutiert hat. POSIX (wie auch andere APIs) beim Design der nativen API im Kopf zu behalten, ist aber sicher nützlich.
Cool wär, wenn mein Beitrag "00:38:31 14.07.2007" kommentieren würde. Das wäre wichtiger. Kommt mir halt vor.
-
keine plugins zu unterstützen ist ein abwürgargument - das fördert stark gebundene designs
grundsätzlich sollte so viel wie sinnvoll erweiterbar / hookbar sein
und es gibt viele sachen wo das sonnvoll ist
z.b. Packetfilter apis, treiber, und für viele userspace tools macht es auch sinn
*edit*
außerdem halte ich es für überaus sinnvoll die leichte portierbarkeit von x11/gtk/qt/kdezu fördern