Archiv verlassen und diese Seite im Standarddesign anzeigen : Design Fragen / HAL
Moin!
Find die Idee, ein OS zu bauen echt klasse, zumal ich es selbst schon oft versucht habe, aber die Leute dazu nicht zusammengekriegt habe...
Hab in nem andren Thread gelesen, dass du (leider) keinen Mircokernel machen willst, sondern evtl. ne Art Hybrid, gibts da schon geneuere Vorstellungen?
Welche Ziele soll das OS im Allgemeinen verfolgen?
Hast du schon Pläne für einen Hardware Abstraction Layer (HAL)?
Wenn nein, arbeite ich gerne mal ein kleines grundsätzliches Modell aus...
PS: *Args* ich weiß, dass mehrere Leute an diesem Projekt beteiligt sind, ist aber einfacher/gewohnter, "du" zu schreiben, bin auch zu faul es zu ändnern ,-)
PS: *Args* ich weiß, dass mehrere Leute an diesem Projekt beteiligt sind, ist aber einfacher/gewohnter, "du" zu schreiben, bin auch zu faul es zu ändnern ,-)Macht nix, da du keinen Namen geschrieben hast trifft "du" auf jeden zu, der antworten will; ich bin der erste.
Prinzipiell habe ich nichts gegen einen Microkernel, ich denke da ist auch noch nicht alles entschieden. Habe grad neulich erst gemerkt, dass ich alles recht modular aufgebaut habe, so dass man im Grunde einiges/alles mögliche als Modul laufen lassen könnte.
Wenn du willst kannst du natürlich gern ein HAL-Modell ausarbeiten, Ideen und Vorschläge sind immer wilkommen.
MfG,
Lizer.
Hansinator
22.09.2004, 12:59
Darüber hab ich mir auch schonmal gedanken gemacht (also über das modulare ;))
Eigentlich bräuchte man die einzelnden funktionen doch nur in ihren eigenen speicherbereich schieben und den scheduler dranlassen, oder ??
Ganz so einfach ist es nun auch wieder nicht. Man bräuchte dafür noch einen "gigantischen" Message- bzw, Signal-Manager, der Nachrichten mit etlichen Daten und Argumenten zwischen den Prozessen hin und her schickt. Das ist auch der Grund, aus dem Minix im Vergleich zu Linux so langsam ist: Das Messaging dauert zu lange. Wenn sich allerdings ein Weg finden lässt, dieses Problem zu umgehen, wäre ein Microkernel vielleicht wirklich die bessere oder zumindest interessantere option für uns.
Okay, ich werd das Modell mal fertig machen und die Tage posten (oder nen Link dazu, wenns größer werden sollte *g*).
Zur Kernelarchitektur:
Ack, das Messaging wird zum Problem, was wohl auch einer der Gründe ist, warum Microkernelarchitekturen im Desktopbereich eher selten anzutreffen sind.
Darum hatteich ja auch gefragt, was die Zielsetzung sein soll, das ist nämlich logischerweise extrem wichtig. Wenn du ein möglichst schnelles OS fürs gamen haben willst, wäre ein mono-kernel z.B. durchaus abgebracht. Oder soll das Ziel Ein stabiles Serversystem sein, dass auch distributed-rechendings (name vergessen :( ) bietet?
Das würde ich auf jeden Fall zuerst entscheiden und alles andere danach richten, je nachdem machen dann ja evtl noch ganz andere (eigene) Architekturen Sinn...
Das "Ziel" ist IMO schon in irgendeinem anderen Thread geklärt worde: 'ne Art Freak-OS zum Spielen, Experimentieren, etc. Es soll (dem Freak) einfach Spaß machen, alle möglichen nützlichen Tools, Spielereien oder was auch immer darauf zu coden. Dabei spielt vor allem eine sinnvolle, sauber programmierte und möglichst kompakte libc 'ne Rolle, andererseits aber auch die Performance.
Die Microkernel-Arch. wäre daher gut, weil es nunmal die z.Z. schönste und sauberste Form ist (zumindest in der Theorie).
Oder soll das Ziel Ein stabiles Serversystem sein, dass auch distributed-rechendings (name vergessen :( ) bietet?
Distributed Computing?
sagrada
Ich glaub er meint Cluster, bin mir aber nicht sicher. :)
Hansinator
22.09.2004, 14:32
Distributed computing wäre ja seti@home z.b. oder irre ich mich jetzt?`
Joa, das messaging hab ich ganz vergessen ...
Da fällt mir wieder der keyboard treiber ein, irgendwie ist der durch motivationsmangel halb versunken wärend meines praktikums.. *schnell wieder an die arbeit mach*
@hansinator: Yo, mach mal hin! Sonst läuft seti unter Midgard und keiner kann was mit anfangen, weil das Keyboard nicht läuft.
*Args* genau clustering war das Wort :-)
Ich hab auch mal nen OS angefangen, AFAIR hatte ich nen grundsätzlichen, primitiven keyboard-driver laufen, wenn ich ihn find, poste ich ihn (Syntax ist aber NASM, das kann ich jetzt schon sagen, weil ich den GNU Asm noch nie benutzt habe.)
Hansinator
22.09.2004, 23:40
ein struktogramm würde reichen ;)
mir gehts um ein paar logiksachen über die ich mir uneins bin..
prinzipiell ist ein scanf fertig, ich bin nur zu faul die scancode tabelle irgendwie einzubauen..
Hab jetzt etwa 100 Zeilen zusammen, darf ich die hier posten oder gibts Boardregeln die das verbieten?
Kannst es auch als TextFile, ZIP oder sontwas anhängen (runter scrollen).
Klingt alles in allem recht interessant. Das mit dem Verbinden von Prozessen finde ich allerdings nicht so sinnvoll. Ich könnte zumindest kein Szenario ausmalen, in dem so eine Funktion benötigt würde (zumindest in der Konsole; innerhalb von Programmen würde das schon eher Sinn machen). Jedenfalls wäre wohl der einzige Nutzen einer solchen Funktion, Ausgaben weiterzuleiten, was sich mit 'normalen' Pipes viel einfacher realisieren lassen würde.
Wie schon in dem File erwähnt müssten das jetzt unbedingt in der Konsole verfügbare Befehle sein. Und wenn man das ganze richtig implementiert gibts soetwas wie pipes nicht, weil die Funktion ja genau das leisten würde (es wäre also kein grundsätzlicher Unterschied zu einer Pipe da und im Idealfall auch nicht aufwendiger).
Wobei ich an dieser Stelle zugeben muss, dass ich mich mit pipes noch nicht viel beschäftigt habe und nicht in allen Eigenheiten kenne.
(es wäre also kein grundsätzlicher Unterschied zu einer Pipe)Gerade deswegen wäre ich eher für Pipes, da die Syntax einfach viel simpler und übersichtlicher ist. Vergleich:
1. cat text | less
2. cat text &
less &
connect process(pidof(cat), 0):process(pidof(less), 0)
Jein. Wie gesagt, die Syntax ist ja beliebig änderbar, die kann man ja z.B. direkt an die Linux-Pipe-Syntax anpassen, weil den Funktionsaufruf connect() ja eh die shell macht und die hat deine Eingabe interpretiert, ich meine, ich könnte dir theoretisch ja auch ne shell für linux schreiben, die "meine" syntax (bzw. eine ähnliche) verwendet, aber bei der shell sind wir ja, denke ich noch nicht.
Übrigens gibt es einen wichtigen unterschied zur Pipe:
Bei meiner "connection" ist die Kommunikation in beide Richtungen möglich.
Nehmen wir z.B. der einfachen Syntax halber '%' als connect(start_process():start_process()) - Infix, kann ich eine shell an den zcpd so hängen:
bash % tcpd
<=> connect(start_process_and_return_pid("bash"):start_...("tcpd"))
Wie gesagt, Syntax ist eine Frage des Kommandozeileninterpreters und davon muss es ja auch nicht nur einen geben, so dass sie Geschmackssache bleiben kann!
PS: Und die "alten" Pipes könnte man dann sogar simulieren, wenn man connect() so flexibel macht, dass es auch die Richtungen begrenzen kann (irgendein zusätzlicher Paramter oder so, und da kann man sogar die "alten" Symbole wieder für nehmen, so dass man erstmal ne gewohnte Umgebung hat