Thema: Wie Ressourcenverwaltung im Micro-Kernel OS?

[kevin]

Da sieht man aber nur die Patches, gibt es eine Möglichkeit auch direkt die Original-Datei und die Ziel-Datei gegenüber zu stellen? Da bekommt man vielleicht eine bessere Vorstellung davon wie einschneidend diese Patches sind.

Hm, nein, so direkt nicht. Du kannst entweder ein Programm hernehmen, das Patches in entsprechender Form darstellt (ich glaube, Kompare kann das beispielsweise) oder halt das Programm zweimal entpacken und einmal die Patches anwenden und einmal nicht.

Besonders aufwändig sehen die Patches so jedenfalls nicht aus, an einigen Stellen wird bloß was auskommentiert o.ä. und an anderen Stellen wird schon ein bisschen mehr geändert. Ich vermute mal das aufwändigste an den Patches war die Suche nach der richtigen Stelle im Code um eine beobachtete Fehlfunktion zu korrigieren.

Ja, das stimmt. Man kann manchmal stundenlang debuggen, um die eine Zeile zu finden, die man auskommentieren muss. Die wirklich aufwendigen Sachen findest du deswegen nicht, weil es uns meistens zu blöd war und wir die Software dann lieber erstmal wieder zur Seite gelegt haben bis die libc soweit ist.

Compilerfehler, wegen nicht vorhandener (Library-)Funktionen, waren sicher eher die Ausnahme, zumindest ab einen gewissen Reifegrad der Librarys.

Du irrst dich. Compilerfehler sind die Regel und die POSIX-Bibliothek wächst mit fast jedem neuen portierten Programm. Wobei Compilerfehler die angenehmere Variante sind als suchen zu müssen, welcher der Stubs jetzt schuld ist, dass das Programm nicht läuft.

Was ich mir auch lustig vorstelle sind Programme die eine Library-Funktion aufrufen (welche erstmal nur als Stub mit Fehlercoderückgabe vorliegt) aber nicht prüfen ob diese wirklich erfolgreich war und dann ein sonderbares Verhalten an den Tag legen.

Das ist vielleicht eine Empfehlung, die man festhalten könnte: Wenn man eine Funktion implementiert, sollte man es richtig tun oder gar nicht. Solche Stubs nützen niemandem und führen nur dazu, dass der Compiler nicht meckert obwohl es nicht funktionieren kann.

Außerdem kann man festhalten: Was der Standard erlaubt, ist im Zweifelsfall egal, wenn sich Linux für eine bestimmte Implementierung entschieden hat und die Programme das jetzt eben erwarten. Und mit den Buildsystemen kann man beim Crosskompilieren auf sein System auch sehr viel Spaß haben.

[bluecode]

Compilerfehler, wegen nicht vorhandener (Library-)Funktionen, waren sicher eher die Ausnahme, zumindest ab einen gewissen Reifegrad der Librarys.

Du irrst dich. Compilerfehler sind die Regel und die POSIX-Bibliothek wächst mit fast jedem neuen portierten Programm. Wobei Compilerfehler die angenehmere Variante sind als suchen zu müssen, welcher der Stubs jetzt schuld ist, dass das Programm nicht läuft.

Meine neueste Errungenschaft dahingehend ist ein Kernellog, in das von Stubs eine Fehlermeldung geschrieben wird. Dann kann man über dmesg sehen wer der Schuldige sein könnte. Kernellog (im Ggs. zu direktem printf) eben va. wegen curses Programmen wie nano oder ähnlichem.

[erik.vikinger]

Hallo,

Hm, nein, so direkt nicht. Du kannst entweder ein Programm hernehmen, das Patches in entsprechender Form darstellt (ich glaube, Kompare kann das beispielsweise) oder halt das Programm zweimal entpacken und einmal die Patches anwenden und einmal nicht.

In beiden Fällen benötige ich aber den passenden Original-Code und darauf hab ich keinen deutlichen Hinweis gesehen, okay ich kenne mich mit patches im Allgemeinen und git im Speziellen auch überhaupt nicht aus. Gibt es da irgendwo eine Liste der zu verwendenden Originale (exakte Version)?

weil es uns meistens zu blöd war und wir die Software dann lieber erstmal wieder zur Seite gelegt haben bis die libc soweit ist.

Aha, auch eine Methode vorwärts zu kommen.

Compilerfehler, wegen nicht vorhandener (Library-)Funktionen, waren sicher eher die Ausnahme, zumindest ab einen gewissen Reifegrad der Librarys.

Du irrst dich. Compilerfehler sind die Regel und die POSIX-Bibliothek wächst mit fast jedem neuen portierten Programm.

Das ist gut, da irre ich mich gerne.

Wobei Compilerfehler die angenehmere Variante sind als suchen zu müssen, welcher der Stubs jetzt schuld ist, dass das Programm nicht läuft.

Da schreibst Du wahr.

Das ist vielleicht eine Empfehlung, die man festhalten könnte: Wenn man eine Funktion implementiert, sollte man es richtig tun oder gar nicht. Solche Stubs nützen niemandem und führen nur dazu, dass der Compiler nicht meckert obwohl es nicht funktionieren kann.

Das klingt aber ungewöhnlich "bodenständig". Ein paar Zeilen höher (und vor 1,5 Monaten) klingt das noch ganz anders.

Außerdem kann man festhalten: Was der Standard erlaubt, ist im Zweifelsfall egal, wenn sich Linux für eine bestimmte Implementierung entschieden hat und die Programme das jetzt eben erwarten.

Im Endeffekt ist es IMHO egal ob irgendein Standard oder irgendein OS den Weg vorgibt, man muss diesen Weg nur finden und auch gehen.

Und mit den Buildsystemen kann man beim Crosskompilieren auf sein System auch sehr viel Spaß haben.

Die Gewissheit das es mir mit meinem Vorhaben ganz sicher nicht langweilig wird beruhigt mich sehr.

Meine neueste Errungenschaft dahingehend ist ein Kernellog, in das von Stubs eine Fehlermeldung geschrieben wird. Dann kann man über dmesg sehen wer der Schuldige sein könnte. Kernellog (im Ggs. zu direktem printf) eben va. wegen curses Programmen wie nano oder ähnlichem.

Das ist eine hervorragend gute Idee, nur leider wird die von der PC-Plattform nicht sonderlich gut unterstützt, vor allem wenn es um Meldungen des Kernel selber geht. Gerade ein Micro-Kernel weiß ja gar nicht das es eine Konsole oder Serielle Schnittstelle gibt und hat eigentlich keine Möglichkeit selbstständig Debug-Meldungen auszugeben. Nach einem Absturz nützt ein Log im RAM nur wenig. Aus diesem Grund habe ich für meine Plattform einen speziellen Logging-NVRAM (mit FRAM realisiert) geplant der immer zur Verfügung steht und per Hardware verwaltet wird. Dieser soll auch bei einem hängendem System (ober bei gedrücktem Reset-Knopf) von Außen per JTAG auslesbar sein. Der mickrige und unzugängliche CMOS-RAM der klassischen PC-Plattform ist für sowas wertlos. Ich möchte fürs Logging 256kByte als Ringpuffer, mit hardwareverwaltetem Schreibpointer (ebenfalls im NVRAM), zur Verfügung stellen. Das ist mehr als ausreichend um mehrere Startversuche des OS aufzuzeichnen bis zu dem Zeitpunkt wo ein beschreibbares Filesystem zur Verfügung steht und der neue NVRAM-Inhalt an eine Log-Datei angehängt werden kann.


Grüße
Erik

[kevin]

In beiden Fällen benötige ich aber den passenden Original-Code und darauf hab ich keinen deutlichen Hinweis gesehen, okay ich kenne mich mit patches im Allgemeinen und git im Speziellen auch überhaupt nicht aus. Gibt es da irgendwo eine Liste der zu verwendenden Originale (exakte Version)?

In den *.lbuild-Dateien steht jeweils (mindestens) eine URL drin, wo es den Original-Tarball zum runterladen gibt.

Das ist vielleicht eine Empfehlung, die man festhalten könnte: Wenn man eine Funktion implementiert, sollte man es richtig tun oder gar nicht. Solche Stubs nützen niemandem und führen nur dazu, dass der Compiler nicht meckert obwohl es nicht funktionieren kann.

Das klingt aber ungewöhnlich "bodenständig". Ein paar Zeilen höher (und vor 1,5 Monaten) klingt das noch ganz anders.

Naja, es ist auch etwas idealistisch gedacht.

In der Praxis kann mal halt nicht alles sofort richtig machen, wenn man in absehbarer Zeit was am Laufen haben möchte. In tyndur kann man aber wenigstens per Define alle Stubs rauskompilieren. Bei den richtig stubbigen Stubs wäre es aber wahrscheinlich besser, wenn man sie in jedes portierte Programm reingepatcht hätte statt sie in die libc zu nehmen. Aus der libc rutschen sie automatisch mit rein, ohne dass man sich dessen richtig bewusst ist.

Im Endeffekt ist es IMHO egal ob irgendein Standard oder irgendein OS den Weg vorgibt, man muss diesen Weg nur finden und auch gehen.

Es gibt da einen wesentlichen Unterschied: Standards sind recht gut dokumentiert, was ein bestimmtes OS üblicherweise macht eher nicht.

[bluecode]

Meine neueste Errungenschaft dahingehend ist ein Kernellog, in das von Stubs eine Fehlermeldung geschrieben wird. Dann kann man über dmesg sehen wer der Schuldige sein könnte. Kernellog (im Ggs. zu direktem printf) eben va. wegen curses Programmen wie nano oder ähnlichem.

Das ist eine hervorragend gute Idee, nur leider wird die von der PC-Plattform nicht sonderlich gut unterstützt, vor allem wenn es um Meldungen des Kernel selber geht. Gerade ein Micro-Kernel weiß ja gar nicht das es eine Konsole oder Serielle Schnittstelle gibt und hat eigentlich keine Möglichkeit selbstständig Debug-Meldungen auszugeben. Nach einem Absturz nützt ein Log im RAM nur wenig.

Der Kernel speichert bei mir nur die Logmeldungen. Ausgegeben wird das (im Normalfall) über ein Userspace Tool namens dmesg (wie unter Linux auch). Die andere Seite ist, dass (weiß nicht, ob das implementiert ist) wenn der Kernel abschmiert (im Sinne von einfachem Fault, beim Triple Fault ist natürlich zu spät) die letzten Logzeilen (durch den kernel) auf den Bildschirm ausgegeben werden. Das ist dann natürlich kein "reiner" Microkernel, man muss aber die Probleme die in der Praxis auftauchen eben auch lösen. Ideologische Scheuklappen sind da fehl am Platz.
Für den oben genannten Zweck ist das Kernellog und Auslesen über dmesg aber vollkommen ausreichend. Ich mein wenn der Kernel abschmiert, dann konnte der Stub auch nichts dafür. Dann sind auch die Meldungen der aufgerufenen Stubs irrelevant.

[erik.vikinger]

Hallo,

In den *.lbuild-Dateien steht jeweils (mindestens) eine URL drin, wo es den Original-Tarball zum runterladen gibt.

Stimmt, hab ich doch glatt übersehen. Ich hatte vor allen nach den Patches gesucht und in den *.lbuild-Dateien ist eben kein C-Code drin also waren diese uninteressant.

Naja, es ist auch etwas idealistisch gedacht.

Ganz ohne Idealismus würde man aber auch nicht anfangen ein eigenes OS zu entwickeln.

In der Praxis ...

Ja die Praxis, ohne die währe alles nur graue langweilige Theorie.

Bei den richtig stubbigen Stubs wäre es aber wahrscheinlich besser, wenn man sie in jedes portierte Programm reingepatcht hätte statt sie in die libc zu nehmen. Aus der libc rutschen sie automatisch mit rein, ohne dass man sich dessen richtig bewusst ist.

Ja, ein berechtigter Einwand. Also lieber eine libc_empty_stubs.h in der nur Zeilen wie

Code: [Auswählen]

static int function(...) { syslog_add("function() is not implemented"); return ERROR_CODE_UNIMPLEMENTED; }drin sind.

Der Kernel speichert bei mir nur die Logmeldungen.

Bei mir soll das direkt die Hardware machen. Ein einfaches strcpy mit Ziel auf den Logging-NVRAM reicht, die geschriebenen Daten werden immer hinten an den Ring-FIFO angehängt unabhängig davon wo die Daten in den Adressraum reingeschrieben werden, die Hardware macht das selbstständig korrekt. So steht das Logging bereits im Initial-Boot-Loader zur Verfügung ohne das die SW dazu irgendetwas machen müsste. Das Auslesen per JTAG ist nur ein Zusatzfeature falls das OS gar nicht mehr will.

Ausgegeben wird das (im Normalfall) über ein Userspace Tool namens dmesg (wie unter Linux auch).

Bei mir soll ein Tool den NVRAM regelmäßig (und beim Start) auslesen und die neuen Meldungen an ein Logfile auf der Festplatte (zur Not auch RAM-Disk) anhängen. dmesg zeigt das Log-File dann nur noch an.

.... die letzten Logzeilen (durch den kernel) auf den Bildschirm ausgegeben werden.

Und wenn es keinen Bildschirm gibt? Wenn Du jede erdenkliche Ausgabemöglichkeit (z.B. RS232 per USB oder SNMP-Trap per Ethernet) im Kernel implementieren möchtest dann wird das ein quasi unmöglicher Job. Ich persönlich finde es besser wenn die Plattform immer ein einfaches (immer gleiches) Logging bietet das man im Notfall auch von Außen auslesen kann. Ich hätte mir vor 3 Jahren auf einer kleinen Embeddedkiste mit nem XScale (damals noch von Intel) sowas sehnlichst gewünscht als der Linux-Kernel einfach nicht starten wollte. Da ist mir diese Idee gekommen.

Das ist dann natürlich kein "reiner" Microkernel,

Was solls, die Erde ist auch nicht perfekt rund und dreht sich trotzdem.

man muss aber die Probleme die in der Praxis auftauchen eben auch lösen. Ideologische Scheuklappen sind da fehl am Platz.

ACK


Grüße
Erik

[erik.vikinger]

Hallo,


ich habe mich nach sehr langem überlegen dann doch für die Variante mit einer Benachrichtigungsliste für jeden Prozess im Kernel entschieden. Die 2 SYSCALLs zum eintragen und austragen pro Service bei dem der Prozess Ressourcen öffnet sind dann wohl doch nicht so schlimm wie ich erst dachte und für die Speicherverwaltung im Kernel wird mir auch was passendes einfallen. Für waitpid kann ich das dann auch gleich mit verwenden. Die Benachrichtigungsmessage über den Prozesstod kann auch zusätzlich den Exit-Code oder eine Info vom Kernel, falls der Prozess mit ner Exception gekillt wurde, enthalten.


Danke für die anregende Diskussion!
Erik