Betriebssystem
-
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
-
@r0nny
Ich hab mich schlecht ausgedrückt: Ich habe gemeint, dass ich keine externen Patches haben will sondern Plugins. Also ich will Plugins möglichst gut fördern. So war das gemeint.Ich bin massiv gegen jede Art der Portierung existierender Pakete. Kein X11, Gtk, QT oder KDE. Es soll was NEUES sein. Wer diese APIs verwenden will, kann das mit Linux tun. Ich möchte, dass ALLES neu ist - auch die GUI. Aber so weit denke ich noch nicht. Ich kann nur wiederholen, dass ein Router der erste Einsatzzweck sein soll. Später soll es dann mit Serveranwendungen weiter gehen sofern ich (noch hat sich niemand als Teammitglied gemeldet. leider) so weit komme.
Vielleicht ist OS das falsche Wort. Ich möchte ein OS plus Pakete. Das ist das Ziel. Es sollten alle notwendigen Pakete selbst erzeugt werden: Abstrakte Datentypen, APIs für Prozess- und Speichermanagment, den Dynamischen Linker, IPC, Netzwerk, Dateisystem, Konsole, GUI, die ganzen Kryptographiealgorithmen, Kompressionsalgorithmen und so weiter. Wichtig ist auch, dass jedes Paket ein existierendes anderes verwendet. Z.B. will ich keine eigene MD5-Implementierung in jedem Paket. Die gibt es dann genau einmal. Das ist das Neue an diesem OS. Alles aus einem Haus sozusagen
-
also willst du eine komplette betriebs-systemsumgebung, in der für jede aufgabe exakt 1 packet / 1 bibliothek exisert, und viel code-reuse betrieben wird
hört sich recht nett an, aber wird es sehr schwer haben anhänger zu finden
würde ich nicht an chronischen zeit-management problemen leiden, würde ich spaßenshalber mitmachen
-
Kann es sein, dass die E-Mail Adresse die du angegeben hast nicht funktioniert.Ich wollte dir schreiben oder bekomme von gmx ne Meldung, dass die Mail Addy nicht existiert !?
-
Mal ne Frage:
Wenns fertig ist, wie teuer solls dann ungefähr werden?
mans nurn paar Euros kostet kann mans ja mal ausprobieren
-
Ich glaube das braucht sehr lange und ob das kommerziell wird..? Glaube nicht
Aber kannst ja mitmachen
-
@r0nny
Genau das habe ich vor. Ich erhoffe mir damit viele Vorteile. Schade, dass du wenig Zeit hast. Du scheinst, sehr kompetent zu sein. Es muss nicht jeder Code schreiben, ich freue mich auch über Diskussionspartner. Falls du dafür Zeit hast, bist du sehr willkommen.@tsluga
Wenn du mich meinst: mastamind@amessage.at is keine Email-Adresse sondern eine Jabber-ID.@Fussel
Das OS wird auf jeden Fall zu 100% Open Source. Geld wird mal nie damit verdienen können. Das OS soll ein Proof-of-Concept sein, dass es möglich ist, so ein großes Projekt zu starten und zum Erfolg zu bringen.Noch was Allgemeines:
Gut wäre, wenn alle jene, die Interesse haben, am OS mitzuarbeiten (in welcher Funktion auch immer), hier reinschreiben, welche ihre bevorzugte Kommunikationsplattform ist. Zur Auswahl stehen vielleicht ICQ, MSN und IRC. Wenn jemandem was anderes einfällt, bitte melden. Ich persönlich bevorzuge massiv Jabber/XMPP. Für alle, die noch nicht wissen, was das is: Es ist ein offenes Protokoll für Instant Messaging mit Support für Chatrooms. http://de.wikipedia.org/wiki/XMPP Da es ein Internetstandard ist und zusätzlich Chatrooms unterstützt, wäre es eine gute Wahl. Ich will aber niemanden zu etwas drängen. Einen Jabber-Server kann ich aufsetzen.
-
Bevor ich ja oder nein sage, würde ich es mir gerne mal anschauen. Also dein Stil, wie es kommentiert ist usw. . Vielleicht weckt es mein interesse.
Wäre nett, wenn du es mir schicken könntest ( tsluga[at]gmx[Punkt]de ) oder einfach mal per ICQ ( 135 15 20 66 ) oder Skype ( tsluga ) ansprechen.
Gruß