Thema: Threads blockieren und wieder aufwecken

[Svenska]

Das läuft auf etwas ähnliches hinaus wie eine andere Diskussion zu ARM. Wir reden also von einer allgemeinen Plattform, nur wer auf Consumer (in Form von Tablets, Desktops, Notebooks und was weiß ich nicht noch alles) abzielt, implementiert diese Plattform, alle anderen halt nicht.

Dann hast du in dieser Diskussion genau garnichts gewonnen. Du zielst nämlich nicht auf das Problem, sondern auf das Symptom ab.

Reicht es nicht, wenn man eine Schnittstelle zur Firmware hat, wo man bestimmte grundlegende Dinge (z.B. ist nen PCI-Bus vorhanden, wenn ja wo ist der gemappt usw.) nachfragen kann. Da sollte es doch auch keine Probleme mit legacy-freien Systemen geben.

Gibt's schon, nennt sich Flatted Device Tree. Wird nur nicht überall implementiert, insbesondere nicht bei irgendwelchen komischen In-House-Bootloadern und selbstverständlich nicht bei Windows CE. Es handelt sich schließlich um eine Linux-Technologie.

Sind dann nicht eigentlich alle Geräte wo ChromeOS drauf läuft per Definition Terminals?

Wenn man "Webbrowsing" als Tätigkeit auffasst nicht, denn das tust du lokal. Im Gegensatz zu Terminals, die mehr oder weniger dumm sind und wo deine Aktivitäten auf dem Server ausgeführt werden.

Aber ja, die Grenze ist nicht besonders hart, denn es gibt auch Terminals, die einige Anwendungen lokal vorhalten. Bleibt der Unterschied, dass (echte) Terminals oft diskless sind oder nur mit wenig Flash ausgestattet und insbesondere den Anwendungen keinen lokalen Speicher zur Verfügung stellen. Es sei denn, man schließt USB-Sticks o.ä. an.

Es gibt ja nunmal Geräte die sollten (es geht bestimmt auch anders) einfach im Kernel sein und dazu zählt z.B. der Timer.

Ja. Und je nach Mainboard, CPU oder BIOS-Implementation sind manche Timer funktionsfähig oder eben auch nicht. Deswegen halte ich den Kernel für die richtige Stelle, den entsprechenden Timer auszusuchen.

Andere Frage: Du hast ein Modul für den zu verwendenden Syscall-Mechanismus. Du unterstützt also mehrere davon. Gibt es ein Fallback, d.h. funktioniert "int 0x80" immer oder nur, wenn die CPU weder SYSENTER noch SYSCALL kann?

Nix saubere Trennung zwischen Bootloader und Kernel, nix Portabilität und vor allem nix gute Interoperabilität mit anderen Betriebssystemen.

Wieso sollte ich eine saubere Trennung zw Bootloader und Kernel wollen? Zwecks Portabilität? Was wenn auf der Ziel-Plattform eh kein Bootloader mit den nötigen Eigenschaften existiert?
Mit dem letzten kann ich gar nix anfangen.

Auf jeder Plattform existiert ein Bootloader, der eine (oder mehrere, notfalls als Archiv) Dateien in den Speicher laden und reinspringen kann. Aber ein Bootloader, der speziell dein Konfigurationsdateiformat und deine Modulstrukturen unterstützt, ist eher selten. Besonders, wenn er zusätzlich noch die Hardware initialisieren muss (was RedBoot und U-Boot können, dein Bootloader muss für jedes einzelne Board angepasst werden; außerdem gibt es sog. Hardware-Quirks je nach Board-Revision).

Wenn jedes Betriebssystem auf dem Rechner von z.B. GRUB geladen werden kann, erhöht das die Interoperabilität verschiedener Betriebssysteme auf einem Rechner ungemein. Sieht man vor allem daran, wenn man Windows neu installiert. Alternative Bootloader sind dann weg. Das ist dein Wunschweg?

Auch bei einem MikroKernel (laut deiner Definition) gibt es Situationen wo dynamisch ladbare Module zur Laufzeit sinnvoll sein kann. Das wären z.B. IRQ-Handler, wenn man die im Kernel haben will oder aber FS-Module, wenn man das VFS im Kernel haben will (was dann mMn kein MikroKernel mehr wäre, aber das ist wieder Geschmackssache).

Dynamisch ladbare Module auf einem Mikrokernel halte ich generell für unnötig, aber vielleicht sehen andere das anders. In meinem Konzept ist der IRQ-Handler vollständig im Kernel, wenn ein IRQ auftritt, wird ein Event an den für diesen IRQ registrierten Treiber geschickt und der schnellstmöglich scheduled. Treiber laufen niemals im IRQ-Kontext. Mein VFS kennt das Konzept einer "Datei" und ein Pseudo-Dateisystem (so ne Mischung aus debugfs, procfs, sysfs oder kernfs), was aber nur die interne Struktur des VFS an sich exportiert. Dateisysteme bleiben Module.

Weil ich Systeme, die mich zum Idioten erklären, nicht leiden kann. Das ist meine Natur, so bin ich, und das kann ich nicht leiden, weil ich mich nicht für einen Idioten halte.

Dann hast du wirklich ein Problem Also ich lasse mir von einem System nicht sagen, ob ich ein Idiot bin oder nicht

Du möchtest aber ein System programmieren, was den Benutzer prinzipiell zum Idioten erklärt, denn er kann ja nichts daran ändern.

Wie gesagt: Nichtmal Windows kann auf Stellschrauben verzichten, sie werden nur besser versteckt.

Ist ja richtig, aber wie viele Benutzer müssen da wirklich ran?

Ich war da öfter drin. Wenn man mit Settop-Boxen zu tun hat (Firmware-Updates oder Streamen des Fernsehsignals - also normale Benutzung), dann gibt es einige Tweaks, die diese Funktionalität erst ermöglichen, weil der Netzwerkstack in den normalen Einstellungen (und den Endnutzer-Windows-Versionen) für diese Lasten nicht ausreichend performt. Dazu muss man kein Guru sein, da gibt es ausgefeilte Scripte und Programme für, die dann ein paar Registry-Einträge verändern, das kriegt auch jeder Depp hin. (Bei Windows-Server sind das die Standardeinstellungen.) Und danach kann man vom DVB-T-Tuner auf eine Windows-Freigabe aufnehmen. Gäbe es die Stellschraube nicht, ginge es nie.

Und was sind das dann für Benutzer? Ich bin halt der Meinung, mit der Zielgruppe die ich habe, das sowas unnötig ist und nur mehr Code und Komplexität für Flexibilität bedeutet.

Das sind Benutzer, die einen Computer für Dinge einsetzen wollen, die der Betriebssystementwickler nicht vorgesehen hat. Wenn deine Zielgruppe nur aus Kindern und ihren Lernprogrammen sowie den Eltern mit dem Browser und Office-Paket besteht, dann hast du vielleicht Recht. Aber auch Familienväter könnten mal das Fernsehprogramm aufzeichnen wollen...

Ich bin mir aber auch darüber im Klaren, dass das auch nicht weit von dem entfernt ist was Apple mit iOS macht, sprich totale Bevormundung des Benutzers. Allerdings bin ich auch der Meinung, dass die meisten Benutzer bevormundet werden sollten, im Sinne aller Wir Freaks machen nunmal den geringeren Teil aus.

Damit betrachte ich die Diskussion für beendet. Implementiere eine Whitelist für Anwendungen. Ach so, und bitte führe die Diktatur wieder ein. Freiheit ist überbewertet.

Gruß,
Svenska,
der grad echt enttäuscht von dir ist.

[PS: Beim Absenden hab ich grad wieder einen HTTP 503 bekommen.]

[FlashBurn]

Dann hast du in dieser Diskussion genau garnichts gewonnen. Du zielst nämlich nicht auf das Problem, sondern auf das Symptom ab.

Wir waren uns doch aber einig, dass auf den meisten MikroKontrollern eine solche Firmware nix verloren hat. Das ist dann halt ne andere Plattform. Problem wird sein es den Herstellern schmackhaft zu machen und MS ist da mMn der richtige für (ob das nun gut ist oder nicht, ist ja erstmal egal). Die haben einfach genug Marktmacht um sowas auch mal durchzudrücken.

Ja. Und je nach Mainboard, CPU oder BIOS-Implementation sind manche Timer funktionsfähig oder eben auch nicht. Deswegen halte ich den Kernel für die richtige Stelle, den entsprechenden Timer auszusuchen.

Naja, aber den Code will ich ja gerade nicht im Kernel haben.

Andere Frage: Du hast ein Modul für den zu verwendenden Syscall-Mechanismus. Du unterstützt also mehrere davon. Gibt es ein Fallback, d.h. funktioniert "int 0x80" immer oder nur, wenn die CPU weder SYSENTER noch SYSCALL kann?

Ich gehe (den deiner Meinung nach falschen) radikalen Weg und es wird dir vorgeschrieben wie du in den Kernel kommst. Es muss immer eine Funktion aufgerufen werden (was hinter Library-Calls versteckt wird) und die hat immer den Code für die optimalste Variante. So ist sicher gestellt das alle Programme auf allen CPUs laufen ohne dass das Programm sowas vorher kontrollieren müsste.

Wenn du trotzdem auf eigene Faust in den Kernel willst, wird es dann vermutlich nach dem Zurückspringen in den UserMode krachen.

Auf jeder Plattform existiert ein Bootloader, der eine (oder mehrere, notfalls als Archiv) Dateien in den Speicher laden und reinspringen kann. Aber ein Bootloader, der speziell dein Konfigurationsdateiformat und deine Modulstrukturen unterstützt, ist eher selten. Besonders, wenn er zusätzlich noch die Hardware initialisieren muss (was RedBoot und U-Boot können, dein Bootloader muss für jedes einzelne Board angepasst werden; außerdem gibt es sog. Hardware-Quirks je nach Board-Revision).

Wenn jedes Betriebssystem auf dem Rechner von z.B. GRUB geladen werden kann, erhöht das die Interoperabilität verschiedener Betriebssysteme auf einem Rechner ungemein. Sieht man vor allem daran, wenn man Windows neu installiert. Alternative Bootloader sind dann weg. Das ist dein Wunschweg?

GRUB kann doch meinen BootloaderBootsektor laden. Zumal ich ja auf anderen Architekturen (wenn es zu umständlich wird, was ohne eine vernünftige Plattform der Fall ist) einfach den Weg der 3.-Stage gehen kann.
Auch Windows kann von GRUB geladen werden, also da sehe ich kein Problem. Das Windows den vorhandenen Bootloader rauskickt ist nen ganz anderes Thema und durchaus ein Problem.

In meinem Konzept ist der IRQ-Handler vollständig im Kernel, wenn ein IRQ auftritt, wird ein Event an den für diesen IRQ registrierten Treiber geschickt und der schnellstmöglich scheduled. Treiber laufen niemals im IRQ-Kontext.

Ich möchte meinen das einige den "kurzen" IRQ-Handler direkt ausführen (ist dort ein Modul des Treibers). Den Weg hatte ich auch mal ganz am Anfang geplant, aber ich habe mich dann dazu entschieden jeden zur Laufzeit hinzufügbaren Code rauszuschmeißen.

Du möchtest aber ein System programmieren, was den Benutzer prinzipiell zum Idioten erklärt, denn er kann ja nichts daran ändern.

Sagen wir mal, am Kernel möchte ich den User nicht rumspielen lassen. Was den UserSpace betrifft (und damit ja eigentlich alle Services), ist das schon wieder was anderes.

Wenn man mit Settop-Boxen zu tun hat (Firmware-Updates oder Streamen des Fernsehsignals - also normale Benutzung), dann gibt es einige Tweaks, die diese Funktionalität erst ermöglichen, weil der Netzwerkstack in den normalen Einstellungen (und den Endnutzer-Windows-Versionen) für diese Lasten nicht ausreichend performt.

Da sehe ich jetzt wieder nicht so das Problem, da der Netzwerkstack erstmal nicht so wichtig ist um das System zum Reagieren zu bringen.

Machen wir es kurz, auf den Kernel wirst du bei meinem OS keinen Einfluss nehmen können, schon gar nicht zur Laufzeit.

Damit betrachte ich die Diskussion für beendet. Implementiere eine Whitelist für Anwendungen. Ach so, und bitte führe die Diktatur wieder ein. Freiheit ist überbewertet.

Wow, der Mensch hat sich in seiner ganzen Lebensgeschichte nicht geändert, sieht immernoch nur schwarz oder weiß Ich bin durchaus der Meinung das der Otto-Normal-Benutzer vor sich selbst beschützt werden sollte. Wozu sonst z.B. irgendwelche Sicherheitsaspekte in das System einbauen, ist ja auch ne Art der Bevormundung.

Und nur mal am Rande, Diktatur hat auch so seine Vorteile, auch wenn man sowas gerade in Deutschland nicht hören will.

[erik.vikinger]

Hallo,

Es gibt ja nunmal Geräte die sollten (es geht bestimmt auch anders) einfach im Kernel sein und dazu zählt z.B. der Timer.

Ja. Und je nach Mainboard, CPU oder BIOS-Implementation sind manche Timer funktionsfähig oder eben auch nicht. Deswegen halte ich den Kernel für die richtige Stelle, den entsprechenden Timer auszusuchen.

Ich finde der Kernel ist eben gerade nicht der richtige Ort um den Kernel je nach vorhandener Hardware zu konfigurieren/initialisieren, das darf ruhig ein vorgelagertes Lade-System machen. Natürlich bedeutet dass das dann beide Komponenten zwingenst zusammenpassen müssen (ist bei meinem System ja nicht anders) aber auch darin sehe ich absolut kein Problem. Ich denke FlashBurn's Fehler ist das er aus seiner Kernel-Initialisierung gleich noch einen Boot-Loader gemacht hat, vielleicht wäre es ein besserer Weg wenn er die Boot-Loader-Funktionalität (laden aller Dateien von HDD usw.) von GRUB o.ä. erledigen lässt und sich darauf konzentriert seinen Kernel passend zur vorhandenen Hardware zu initialisieren/zusammenzusetzen.

Andere Frage: Du hast ein Modul für den zu verwendenden Syscall-Mechanismus. Du unterstützt also mehrere davon. Gibt es ein Fallback, d.h. funktioniert "int 0x80" immer oder nur, wenn die CPU weder SYSENTER noch SYSCALL kann?

Wozu ein Fallback wenn er sicherstellen kann das alle normalen Programme wie gewünscht funktionieren? Klar, ich würde vermutlich auch einen Fallback einbauen, aber hat nicht auch FlashBurn recht wenn er dagegen hält dass das unnütze Speicherverschwendung ist?

In meinem Konzept ist der IRQ-Handler vollständig im Kernel, wenn ein IRQ auftritt, wird ein Event an den für diesen IRQ registrierten Treiber geschickt und der schnellstmöglich scheduled. Treiber laufen niemals im IRQ-Kontext.

Da sind wir Drei uns doch eigentlich einig. Der Grund warum FlashBurn dafür verschiedene Module (mit nach außen identischer Funktionalität) haben möchte liegt doch darin begründet das die x86-Plattform ziemlich unterschiedliche IRQ-Controller hat (die sind vor allem so arg unterschiedlich das es nicht reichen würde nur an ein paar Stellen im Quell-Code eine winzige Verzweigung o.ä. einzubauen). FlashBurn hat da genau 2 Möglichkeiten: entweder er untersützt nur eine Sorte IRQ-Controller und verliert dabei erheblich an Funktionalität (beim alten PIC) bzw. kann nur die neuen PCs unterstützen (beim neuen APIC) oder er unterstützt andererseits alle IRQ-Controller. FlashBurn hat sich für letzteres entschieden und ich persönlich finde seine Entscheidung, aber auch seine Lösung für die daraus resultierenden Probleme, gut. Klar mag das auch etwas seinem Naturell, möglich komplexe Lösungen zu bevorzugen, entsprechen aber so ist er nun mal, das wird keiner von uns ändern.

Und was das Thema Stellschrauben angeht: FlashBurn kennt doch jetzt einen Weg wie er seinen Automatismus mit einer Stellschraube versehen kann, lassen wir ihn das doch erst mal implementieren und meckern dann weiter.

Es mag ja sein, dass sie den verschiedenen IRQs verschiedene Prioritäten geben, aber ich denke nicht dass sie sie zur Laufzeit dynamisch ändern.

Vermutlich nicht, aber zum einen könnte man das sicher einbauen und zum anderen kann ein HW-Gerät ja mehrere IRQs haben die dann fest unterschiedliche Prioritäten haben und es wird für jeden Job ein passender IRQ ausgewählt.

Ich habe keine Ahnung an welchem Takt so ein IO-APIC hängt, wären pro IRQ 4 32bit Zugriffe (2x lesen und dann 2x schreiben).

Das Ändern einer IRQ-Priorität sollte bei den APICs auf einen einzigen Schreibzugriff hinaus laufen.

Ich denke aber mal fast das aufwendigste wäre sich nen neuen INT-Vektor zu holen und den alten gegebenenfalls (wenn man denn nen neuen bekommen hat) freizugeben.

Wieso willst Du neue INT-Vektoren zuweisen? Das ist doch Quatsch und sicher auch gar nicht so einfach machbar zur Laufzeit, es müsste ja auch atomar durchgeführt werden und da dürften die üblichen HW-Geräte nicht so einfach mitspielen bzw. man bräuchte entsprechende Unterstützung durch die Treiber.

hätte nicht gedacht dass das so langsam ist.

Doch, I/O-Port sind extrem langsam, im Verhältnis zum Speicher. Deswegen unterstützt ja auch kaum eine andere Plattform I/O-Ports, die meisten kennen nur Speicher.

Wobei ich denke, dass RS232 vllt nen schlechtes Bsp ist. Denn mir fällt gerade nix ein, wo man das nutzt und dann nicht gerade die Anwendung die wichtigste ist (dir doch bestimmt ).

Viele ältere ISDN-Anlagen werden per RS232 konfiguriert und das ist meistens nicht so wichtig wie der MP3-Player im Hintergrund (ist doch egal ob die Konfiguration 2,0 Sekunden oder 2,1 Sekunden benötigt). Auch gibt es immer noch recht viele managed Ethernet-Switches mit ner RS232-Konsole (da muss der Admin zwar persönlich und mit Laptop vor Ort sein aber dafür funktioniert die wenigstens immer, selbst wenn das LAN mal komplett tot oder kaputt-konfiguriert ist), dem Admin dürfte der MP3-Player im Hintergrund auch wichtig genug sein das dieser eine höhere Priorität bekommt als das Terminal-Programm (wenn der Admin ne hundertstel Sekunde länger braucht ist das schließlich immer noch bezahlte Arbeitszeit).

und da hilft es nix, wenn man ständig die Antwort auf ein Problem bekommt, nutz halt was anderes (was du übrigens auch oft mit deinen Segmenten gemacht hast ).

Ja, ich weiß, meine Antworten sind auch nicht immer sehr hilfreich.
Jeder hat eben so seine Vorstellungen und sieht auch ganz spezielle Vorteile darin, da kommt dann eben auch mal eine Antwort in der Art "is doch gar kein Problem, mach das so wie ich und schon ist alles in Butter".


Grüße
Erik

[FlashBurn]

Ich denke FlashBurn's Fehler ist das er aus seiner Kernel-Initialisierung gleich noch einen Boot-Loader gemacht hat, vielleicht wäre es ein besserer Weg wenn er die Boot-Loader-Funktionalität (laden aller Dateien von HDD usw.) von GRUB o.ä. erledigen lässt und sich darauf konzentriert seinen Kernel passend zur vorhandenen Hardware zu initialisieren/zusammenzusetzen.

Das könnte ich auch immernoch machen, aber mich hat es halt auch interessiert wie sowas funktioniert, wie man ein allgemeines Interface anbietet (einmal um eine Datei zu laden und einmal um einen Sektor zu laden) und damit hatte ich dann GRUB ersetzt

Ist es eigentlich möglich GRUB zur Laufzeit (von GRUB) zu konfigurieren? Ich habe bei mir ein Bootmenü mit drin, wo ich im Moment nur die Auflösung für VBE wählen kann, aber da könnte ich auch so Sachen wie den Scheduler auswählen lassen. Was dann wieder gegen GRUB sprechen würde, weil ich nach der Auswahl im Menü z.B. auch ganz andere Module laden würde (wahrscheinlich).

Klar, ich würde vermutlich auch einen Fallback einbauen, aber hat nicht auch FlashBurn recht wenn er dagegen hält dass das unnütze Speicherverschwendung ist?

Warum würdest du einen Fallback einbauen? Mir geht es dabei nicht mal um die "Speicherverschwendung".

Ich sehe es so, der Kernel bietet eine API an und an die hat man sich zu halten (ist doch unter Linux und allen andern OS´en nicht anders) und diese sieht vor, dass man nur in den Kernel kommt, indem man eine bestimmte Funktion aufruft.
Durch diese Abstraktion stelle ich sicher, dass immer die best mögliche Variante genutzt wird, egal wie alt das Programm ist und ohne das sich das Programm darum kümmern muss (ich nehme dem Programmierer Arbeit ab).
Dazu kommt noch, stell dir vor du müsstest Grafikhardware direkt und nicht über DirectX/OpenGL programmieren. Dann müsstest du für jede Graka nen eigenen Treiber schreiben und würdest nie alle Unterstützen können und deine Software würde irgendwann nicht mehr funktionieren. Durch solch ein Interface ist sichergestellt das der Programmierer solche Details nicht kennen muss.
Zumal man eigentlich auch nicht Direkt mit dem Kernel zu tun haben sollte, sondern sowas immer über eine Library abstrahiert sein sollte. Alleine schon, falls sich das Interface zum Kernel mal ändern sollte.
Ich sehe darin keine Nachteile, sondern nur Vorteile.

Vermutlich nicht, aber zum einen könnte man das sicher einbauen und zum anderen kann ein HW-Gerät ja mehrere IRQs haben die dann fest unterschiedliche Prioritäten haben und es wird für jeden Job ein passender IRQ ausgewählt.

Wenn die Hardware in der Lage ist mehrere verschiedene IRQs zu produzieren, dann stimme ich dem zu.

Das Ändern einer IRQ-Priorität sollte bei den APICs auf einen einzigen Schreibzugriff hinaus laufen.

Nope, du liest einmal um den INT-Vektor (und genau der repräsentiert die Priorität/legt sie fest) auszulesen, diesen freizugeben und dir nen neuen zu holen (das wäre das Schreiben).

Wieso willst Du neue INT-Vektoren zuweisen? Das ist doch Quatsch und sicher auch gar nicht so einfach machbar zur Laufzeit, es müsste ja auch atomar durchgeführt werden und da dürften die üblichen HW-Geräte nicht so einfach mitspielen bzw. man bräuchte entsprechende Unterstützung durch die Treiber.

Da der INT-Vektor aber die Priorität festlegt, weißt du jetzt warum das nicht dynamisch gemacht wird

Doch, I/O-Port sind extrem langsam, im Verhältnis zum Speicher. Deswegen unterstützt ja auch kaum eine andere Plattform I/O-Ports, die meisten kennen nur Speicher.

Hieße das auch, dass ein USB-RS232-Adapter viel besser ist als eine native Schnittstelle?

Viele ältere ISDN-Anlagen werden per RS232 konfiguriert und das ist meistens nicht so wichtig wie der MP3-Player im Hintergrund (ist doch egal ob die Konfiguration 2,0 Sekunden oder 2,1 Sekunden benötigt). Auch gibt es immer noch recht viele managed Ethernet-Switches mit ner RS232-Konsole (da muss der Admin zwar persönlich und mit Laptop vor Ort sein aber dafür funktioniert die wenigstens immer, selbst wenn das LAN mal komplett tot oder kaputt-konfiguriert ist), dem Admin dürfte der MP3-Player im Hintergrund auch wichtig genug sein das dieser eine höhere Priorität bekommt als das Terminal-Programm (wenn der Admin ne hundertstel Sekunde länger braucht ist das schließlich immer noch bezahlte Arbeitszeit).

Naja, das man die Priorität nicht dynamisch zur Laufzeit ändern kann, sollte dir inzwischen klar sein

RS232 wird ja auch noch viel in der Industrie eingesetzt. Dass der IRQ-Handler aber immer ne höhere Priorität als der MP3-Player hat, lässt sich wohl nicht so wirklich vermeiden. Ich wollte eigentlich keine ganzen Programme in die Real-Time-Priorität reinlassen, sondern nur die IRQ-Handler oder spricht da was dagegen?

Ja, ich weiß, meine Antworten sind auch nicht immer sehr hilfreich.

Hast dich aber gebessert.

Was ich dazu noch sagen kann, in der Uni bekommt man ganz bestimmte Aufgaben und wenn da mal jemand ein Problem hat und andere immer nur ankommen und sagen, ne das ist doof, nimm doch lieber das und das. Dann hilft dem das gar nicht weiter. Der soll das nehmen und gut ist. Ist ja leider in der reallen Welt genauso (da wo man jemanden über sich hat).

[erik.vikinger]

Hallo,

Warum würdest du einen Fallback einbauen? Mir geht es dabei nicht mal um die "Speicherverschwendung".

Hm, so nach etwas nachdenken bin ich mir auch nicht mehr so sicher. Das Problem was ich sehe ist das Du mit Deinem Weg statisches Linken (zumindest der libc) grundsätzlich ausschließt und das gefällt mir persönlich gar nicht, damit wird auch LTO eingeschränkt. Ich denke die meisten Hobby-OSe benutzen nur statisch gelinkte Executables, einfach weil man sich damit das fertig-linken im Executable-Loader sparen kann (ist ja doch kein so ganz einfaches Thema und für den ersten Anlauf kann man eigentlich auch gut drauf verzichten). In meinem Projekt wird es wohl zum Anfang auch nur statisch gelinkte Executables geben, für was besseres bräuchte ich auch ein neues Executable-Format und müsste mir auch überlegen wie ich das bei den OpCodes meiner CPU überhaupt hinkriegen kann (ich müsste für die unrelozierten Calls wohl immer die maximale OpCode-Größe benutzen). Prinzipiell sehe ich kein Problem darin wenn der Kernel immer alle Wege anbietet die die CPU auch unterstützt (was nicht geht endet eh in einer Exception). Das Kernel-Syscall-API sollte sich auch möglichst niemals ändern sondern nur um neue Funktionen erweitert werden. Auf der anderen Seite ändert sich das Kernel-Syscall-API bei Windows auch mit jeder Version (oft sogar bei Service-Packs) erheblich, Windows unterstützt wimre auch nur sehr begrenzt fertig gelinkte Executables (solche Executables laufen dann nur unter einer ganz bestimmten Windows-Version).

Das Ändern einer IRQ-Priorität sollte bei den APICs auf einen einzigen Schreibzugriff hinaus laufen.

Nope, du liest einmal um den INT-Vektor (und genau der repräsentiert die Priorität/legt sie fest) auszulesen, diesen freizugeben und dir nen neuen zu holen (das wäre das Schreiben).

Ich will Dir ja nicht widersprechen aber es fällt mir wirklich extrem schwer zu glauben das bei den 24 IRQs die so ein I/O-APIC unterstützt nicht auch jeder IRQ ein individuelles Prioritätsregister hat, ließ da Bitte noch mal in der APIC-Spec genau nach. Ich kann mir einfach nicht vorstellen das die Intel-Ingeniöre solch kapitale Fehler gemacht haben.

Hieße das auch, dass ein USB-RS232-Adapter viel besser ist als eine native Schnittstelle?

Jain, so ein USB-RS232-Adapter erzeugt auf dem PC auf jeden Fall eine deutlich geringere CPU-Last (eben weil der USB-Host-Controller, zumindest seit EHCI, die Daten als Busmaster in den RAM legt bzw. von dort holt) aber man hat auch deutlich längere Latenzen (was u.a. durch das Framing im USB-Protokoll begründet ist). Ich hab mal für eine spezielle Industrie-Anwendung eine Multi-RS232-Karte auf FPGA-Basis entwickelt und mein UART hat auch alles als Busmaster erledigt so das nur alle paar kB mal ein IRQ erforderlich war, damit konnte der Linux-PC ohne spürbare CPU-Last 4 RS232-Verbindungen mit 1,9MBaud voll duplex sättigen, das wäre mit klassischen UARTs nicht möglich gewesen.

Ich wollte eigentlich keine ganzen Programme in die Real-Time-Priorität reinlassen, sondern nur die IRQ-Handler oder spricht da was dagegen?

Es spricht IMHO was dagegen das Du aus der "Real-Time"-Priorität was besonderes machst. Wenn Du einfach X Prioritäten hast dann sollte es grundsätzlich möglich sein das sowohl IRQ-Handler als auch normale Threads jede dieser Prioritäten haben können (wobei die höheren Prioritäten auf jeden Fall ausreichend geschützt werden müssen aber das ist ein anderes Problem).

Hast dich aber gebessert.

Danke, ich gebe mir auch Mühe, zumindest hin und wieder.


Grüße
Erik

[FlashBurn]

Das Problem was ich sehe ist das Du mit Deinem Weg statisches Linken (zumindest der libc) grundsätzlich ausschließt und das gefällt mir persönlich gar nicht, damit wird auch LTO eingeschränkt.

Wieso, ich stelle diese Funktionen auch als statische Libraries zur Verfügung.

Ich denke die meisten Hobby-OSe benutzen nur statisch gelinkte Executables, einfach weil man sich damit das fertig-linken im Executable-Loader sparen kann (ist ja doch kein so ganz einfaches Thema und für den ersten Anlauf kann man eigentlich auch gut drauf verzichten).

Also das will ich nicht. Dynamische Libraries sollen bei mir eigentlich Standard sein (vom RT-Linker, VFS-Server und Device-Server mal abgesehen).

Ich will Dir ja nicht widersprechen aber es fällt mir wirklich extrem schwer zu glauben das bei den 24 IRQs die so ein I/O-APIC unterstützt nicht auch jeder IRQ ein individuelles Prioritätsregister hat, ließ da Bitte noch mal in der APIC-Spec genau nach. Ich kann mir einfach nicht vorstellen das die Intel-Ingeniöre solch kapitale Fehler gemacht haben.

Unlike IRQ pins of the 8259A, the notion of interrupt priority is completely unrelated to the position of the
physical interrupt input signal on the APIC. Instead, software determines the vector (and therefore the priority)
for each corresponding interrupt input signal.

Sollte doch als "Beweis" reichen oder

[erik.vikinger]

Hallo,

Wieso, ich stelle diese Funktionen auch als statische Libraries zur Verfügung.

Aber sobald diese Library ins Executable eingelinkt wurde ist das Executable fest. Wenn Du dort die Library-Version einbaust die INT für Syscalls benutzt aber das Executable dann auf einem PC laufen soll der SYSENTER will geht Dein Executable nicht mehr. Das ist irgendwie doof, oder? Vor allem weil man ja durchaus auch mal wegen der Performance statisch linken möchte (damit selbst die libc von LTO profitiert).

Dynamische Libraries sollen bei mir eigentlich Standard sein

Wenn Du das sauber hinkriegst ist das natürlich toll.

..... Sollte doch als "Beweis" reichen oder

Hm, da bin ich echt platt, die meisten IRQ-Controller mit denen ich bis jetzt zu tun hatte haben für jeden IRQ ein individuelles Priority-Register (selbst bei Intel-Produkten wie einem PXA270). Mein IRQ-Controller soll das auch haben, einfach weil ich das als absolut normale Selbstverständlichkeit betrachte, trotz dessen dass das Logik-Ressourcen im FPGA frisst.


Grüße
Erik

[FlashBurn]

Aber sobald diese Library ins Executable eingelinkt wurde ist das Executable fest. Wenn Du dort die Library-Version einbaust die INT für Syscalls benutzt aber das Executable dann auf einem PC laufen soll der SYSENTER will geht Dein Executable nicht mehr. Das ist irgendwie doof, oder? Vor allem weil man ja durchaus auch mal wegen der Performance statisch linken möchte (damit selbst die libc von LTO profitiert).

Manchmal denke ich ihr wollt mich nicht verstehen

Hast du dich schonmal mit den Syscall-Methoden unter Linux und Windows beschäftigt?

Also mal ganz genau beschrieben, der Caller packt seine Parameter auf den Stack (ja die werden nicht über die Register weitergereicht, da die dann eh auf den Kernel-Stack gepackt werden müssen und kopieren muss man auch wenn es zu viele sind) und callt die von mir zur Verfügung gestellt Funktion. Diese Funktion macht nix anderes, als die Funktionsnr (vom Kernel-API) in EAX zu packen und einen "jmp" zu einer festen Adresse zu machen und das ist jetzt der Punkt wo es transparent für die Anwendung ist. Denn an dieser festen Adresse steht der Code für nen kleinen Stub der in den Kernel springt und genau hier wird dann die jeweils beste zur Verfügung stehende Methode genutzt.
Dazu braucht man weder dynamische Libraries noch wird in das Programm irgendetwas reingelinkt was mit der eigentlich verwendeten Methode zu tun hat.

Diese Page (bisher ist es nur eine) ist am oberen Ende eines jeden Adressraumes gemappt. Da können dann auch noch mehr Sachen rein (Haiku stellt so z.B. optimierte memcpy und Konsorten zur Verfügung und ich wollte das eigentlich auch noch so machen) und diese Adressen ändern sich nicht. Man muss halt sehen wie viel da rein soll, sprich ob es Sinn macht in der oberesten Page nur Adressen auf Funktionen zu speichern oder (so wie ich bisher) da schon direkt Code reinzuschreiben.

Wenn Du das sauber hinkriegst ist das natürlich toll.

Wenn du das so schreibst klingt das als wenn du schon eine Idee hast was da schief gehen könnte bzw. wo es Probleme geben wird?

Nochmal zum IO-APIC, soweit ich es verstanden habe, sind dem die Prioritäten auch eigentlich egal. Die Lokalen-APICs interessiert das dann erst.

Ich habe mir heute nochmal (versucht) GRUB und auch U-Boot näher anzuschauen und nein, definitiv nicht als einziger Bootloader. Alleine schon durch die Tatsache das ich einige Annahmen mache wo meine Module liegen, macht es die Sache einfacher. Soweit ich es verstanden habe, werden die Module bei GRUB1 direkt hinter den Kernel geladen (ich gehe davon aus, dass das mit 4kb alignt passiert, habe dazu aber nix gefunden) und bei GRUB2 irgendwo in den höheren Speicher. Ich denke fast mal mit GRUB2 werden wohl einige Hobby-OS´s Probleme genau deswegen bekommen.
In der U-Boot Doku habe ich gar nix gefunden wie man andere Systeme oder Kernel allgemein lädt, da ist alles auf Linux bezogen, von Multiboot auch keine Spur. D.h. also wenn man auf eine andere Architektur will und dann nicht mehr GRUB nutzen kann, muss man sich sowieso was einfallen lassen.

Wenn jemand mal nen Link zu einer halbwegs guten Doku (oder wenigstens irgendwelche interessanten Infos) zu fastboot (Android) hat, wäre ich sehr dankbar dafür.

Ich bin immernoch überzeugter eigener-Bootloader-Nutzer

[erik.vikinger]

Hallo,

Manchmal denke ich ihr wollt mich nicht verstehen

Was Du da beschreibst hast Du in diesem Thread auch noch gar nicht erwähnt und leider kann ich mir nicht zu jedem hier diskutiertem OS alle intimen Details merken. Wobei dieser Weg immer zwei zusätzliche Indirektionen hat, im Gegensatz dazu wenn der richtige Syscall-Befehl direkt in den User-Code geinlined wird (was mit LTO bei kleinen libc-Funktionen ja problemlos möglich wäre). Irgendwie verstehe ich Dich wirklich nicht, da nimmst Du einen riesigen Aufwand mit einem zur Boot-Zeit zusammengelinkten Kernel in kauf nur um eine einzige Indirektion zu sparen und dann baust Du gleich zwei davon in den User-Mode ein. Was soll ich den jetzt noch über Dich denken?

Hast du dich schonmal mit den Syscall-Methoden unter Linux und Windows beschäftigt?

Sicher nicht annähernd so ausgiebig wie Du. Die x86-Plattform ist auch die einzigste bei der das so ein komplexes Thema ist, alle anderen Plattformen haben einen spezifischen Syscall-Befehl, der von der CPU möglichst performant unterstützt wird, und gut.

Wenn du das so schreibst klingt das als wenn du schon eine Idee hast was da schief gehen könnte bzw. wo es Probleme geben wird?

Nö nö, keine Sorge, ich bin bloß der Meinung das gerade das Thema Linken gerade für OS-Dev-Anfänger eher nicht so geeignet ist und daher viele diesen Punkt auf eine spätere Version vertagen. Ich glaube tyndur kann das auch noch nicht, falls ich mich irre so möge man mich Bitte korrigieren.

Ich bin immernoch überzeugter eigener-Bootloader-Nutzer

Ich kann Dich da gut verstehen. Obwohl ich als Ausweg lieber eine Art Init-RAM-Disk nehmen würde in der der eigentliche Kernel mit allen potentiellen Komponenten und auch alle wichtigen Services, die ein Micro-Kernel-OS ja benötigt damit weitere User-Mode-Programme von HDD geladen werden können, drin sind und dazu ein Programm (welches für den Boot-Loader als Kernel behandelt wird) das daraus dann ein lauffähiges System zusammenbaut. Problem dabei wäre natürlich das Du dann von der Vorbereitung des virtuellen Speichers durch den Boot-Loader abhängig bist aber ich denke auch das lässt sich lösen.


Grüße
Erik

[FlashBurn]

Was Du da beschreibst hast Du in diesem Thread auch noch gar nicht erwähnt und leider kann ich mir nicht zu jedem hier diskutiertem OS alle intimen Details merken.

Habe ich nicht? Mir war so

Wobei dieser Weg immer zwei zusätzliche Indirektionen hat, im Gegensatz dazu wenn der richtige Syscall-Befehl direkt in den User-Code geinlined wird (was mit LTO bei kleinen libc-Funktionen ja problemlos möglich wäre). Irgendwie verstehe ich Dich wirklich nicht, da nimmst Du einen riesigen Aufwand mit einem zur Boot-Zeit zusammengelinkten Kernel in kauf nur um eine einzige Indirektion zu sparen und dann baust Du gleich zwei davon in den User-Mode ein. Was soll ich den jetzt noch über Dich denken?

Das Inlinen geht ja nicht, dadurch dass es verschiedene Methoden gibt. Als Bsp. was machst du wenn der Code die syscall/sysret Variante nimmt (AMD) und auf einer Intel CPU läuft?
Wieso eigentlich 2 Indirektionen (steh da gerade aufm Schlauch)? Wegen einmal "call" und einmal "jmp"?

Mir wäre es am liebsten wenn man dem Compiler irgendwie sagen könnte, dass er diese bestimmte Adresse callen soll und die Parameter auf den Stack pusht. Also wenn jemandem sowas bekannt ist, immer her damit.

Aber wo ich da gerade so drüber nachdenke, kann man nicht einfach ne Funktion "bool sendMsg(buffer,receiver,flags);" definieren und dann beim Laden des Programms das Symbol auflösen? Damit würde ich mir ja eine Indirektion sparen (wieso bin ich da nicht früher draufgekommen).

Zumal auch das mit dem Inlinen aus einem anderen Grund doof ist, "syscall"/"sysenter" sind nicht so einfach wie ein "int", da muss man erst Register sichern und bestimmte Sachen in diese Register laden oder das passiert automatisch (ich mag die beiden Varianten nicht so, aber sie sind halt schneller als "int"). Deswegen habe ich auch nen Stub dafür (und mache leider noch keine Überprüfungen ob die Rücksprungadresse wirklich ok ist).

Fällt dir denn ne bessere Variante ein? Deswegen habe ich das bisher so gemacht, mir ist keine bessere (kompliziertere ) eingefallen.

Die x86-Plattform ist auch die einzigste bei der das so ein komplexes Thema ist, alle anderen Plattformen haben einen spezifischen Syscall-Befehl, der von der CPU möglichst performant unterstützt wird, und gut.

Warum ist das eigentlich bei x86 so kompliziert? Ist das nicht auch wegen den Segmenten so?

Nö nö, keine Sorge, ich bin bloß der Meinung das gerade das Thema Linken gerade für OS-Dev-Anfänger eher nicht so geeignet ist und daher viele diesen Punkt auf eine spätere Version vertagen.

Also object-files in ein executeable-file zu linken ist gar nicht so schwer. Viel schwieriger sind dann schon die shared-libraries, aber auch das sollte (wenn man das vorherige kann) nicht so schwierig sein.

Obwohl ich als Ausweg lieber eine Art Init-RAM-Disk nehmen würde in der der eigentliche Kernel mit allen potentiellen Komponenten und auch alle wichtigen Services, die ein Micro-Kernel-OS ja benötigt damit weitere User-Mode-Programme von HDD geladen werden können, drin sind und dazu ein Programm (welches für den Boot-Loader als Kernel behandelt wird) das daraus dann ein lauffähiges System zusammenbaut. Problem dabei wäre natürlich das Du dann von der Vorbereitung des virtuellen Speichers durch den Boot-Loader abhängig bist aber ich denke auch das lässt sich lösen.

Du musst dann deinen Loader auch an jeden Bootloader anpassen oder im Falle von U-Boot vllt sogar nen Linux-Kernel emitieren (keine Ahnung ob das wirklich nötig oder schwer ist).
Da du dann ja eigentlich auch Dinge machst, die der erste Bootloader schon kann, kannst du den auch gleich selber schreiben. Mit einer Ausnahme, wenn der erste Bootloader die Firmware darstellt. Da macht es dann wenig Sinn dieses neu zu schreiben.

Ich habe da mit nem eigenen Bootloader auf x86 eventuell weniger Arbeit, weil entweder du musst deinen Loader an mehrere Bootloader anpassen oder der User müsste deinen Bootloader nutzen (was bei mir der Fall ist, aber das ist das gleiche als ob du Windows damit laden würdest).

Da gefällt mir der Bootloader vom Raspberry Pi sogar besser als U-Boot oder so. Da wird einfach ne bestimmte Datei an eine festgelegt Adresse geladen und einfach dahin gesprungen. Damit kann ich arbeiten

[erik.vikinger]

Hallo,

Das Inlinen geht ja nicht, dadurch dass es verschiedene Methoden gibt.

Eben, das ist es ja warum ich der Meinung bin dass das bei x86 deutlich komplexer ist als bei anderen CPU-Architekturen.

Wieso eigentlich 2 Indirektionen?

Na einmal weil Du vom normalen Code in die entsprechende Library springen musst (solange Du nicht statisch linkst und dabei LTO benutzt bleibt das auch) und dann muss die Library noch in Deine Spezial-Page springen (solange Du flexibel alle 3 möglichen Wege von x86 anbieten möchtest bleibt das auch). Ob das per CALL oder per JMP gemacht wird macht erstmal keinen so großen konzeptionellen Unterschied. Bei mir ist der SYSCALL-Befehl direkt in der Library drin und der Compiler hat beim statischen Linken per LTO noch die Möglichkeit auch das direkt in den User-Code zu inlinen.

Mir wäre es am liebsten wenn man dem Compiler irgendwie sagen könnte, dass er diese bestimmte Adresse callen soll und die Parameter auf den Stack pusht. Also wenn jemandem sowas bekannt ist, immer her damit.

Du könntest einen Funktionsprototypen als typedef deklarieren und in Deinem Code eine Konstante (die das Sprungziel darstellt) in einen Funktions-Pointer mit diesem Typ casten und das dann direkt aufrufen, wenn Du das in ein passendes Makro verpackst dürfte das sogar recht hübsch aussehen.

Du musst dann deinen Loader auch an jeden Bootloader anpassen oder im Falle von U-Boot vllt sogar nen Linux-Kernel emitieren

Wenn Du Deinen Loader Multiboot-kompatibel machst sollte das meiste schon mal funktionieren und wenn Dein Loader dann noch so aussieht wie ein Linux-Kernel dürftest Du mit (fast) jedem Open-Source-Boot-Loader auf (fast) allen Plattformen klar kommen.


Grüße
Erik

[FlashBurn]

Du könntest einen Funktionsprototypen als typedef deklarieren und in Deinem Code eine Konstante (die das Sprungziel darstellt) in einen Funktions-Pointer mit diesem Typ casten und das dann direkt aufrufen, wenn Du das in ein passendes Makro verpackst dürfte das sogar recht hübsch aussehen.

Hätte ich damit nicht wieder eine Indirektion (durch den Funktionspointer)? Diese Variante hätte natürlich den Vorteil, dass sie keinen Linker erfordert.

Wenn Du Deinen Loader Multiboot-kompatibel machst sollte das meiste schon mal funktionieren und wenn Dein Loader dann noch so aussieht wie ein Linux-Kernel dürftest Du mit (fast) jedem Open-Source-Boot-Loader auf (fast) allen Plattformen klar kommen.

Naja, aber selbst Multiboot-kompatibel ist ja nur die halbe Miete (für den normalen OS-Dever). Wenn man das richtig macht dann sollte das klappen, aber auch das ist schon verdammt aufwendig. Man muss immer vom schlimmsten ausgehen und aufs beste hoffen

Ein anderes Problem lässt sich leider weder durch einen eigenen Bootloader noch durch eine eigenen 3.-Stage lösen. Denn selbst wenn dein Loader aussieht wie ein Linux-Kernel (ich wüsste nichtmal was das heißt), gibt es noch die ganzen Architekturen außerhalb von x86
Ich kenne es nur vom Toshiba AC100 (ARM Cortex-A9 und von nVidia), aber da müssen sogar ein paar Werte im Kernel (ich vermute mal repräsentiert durch ein Symbol) ganz genau so sein wie es (in dem Fall) fastboot haben möchte. Und diese Werte können sich schon durch ein Update ändern (das war mal nen Problem bzw. ist es für einige immernoch).

Lange Rede kurzer Sinn, außerhalb von x86 hat man sowieso ganz schön Arbeit und kann nicht mal eben eine Datei (was teilweise schon geht) oder eine bestimmte Datei laden lassen.

[Svenska]

Lange Rede kurzer Sinn, außerhalb von x86 hat man sowieso ganz schön Arbeit und kann nicht mal eben eine Datei (was teilweise schon geht) oder eine bestimmte Datei laden lassen.

Das geht sogar ganz wunderbar, wenn du dich auf eine Plattform beschränkst. Du sagst "x86", meinst aber "ibmpc".
Es gibt keine ARM-Betriebssysteme, es gibt auch keine x86-Betriebssysteme.
Es gibt sie aber fürn PC, fürs Galaxy Tab, fürn PNA 200S, fürn Zaurus, fürn Nexus One oder für den WLAN-Chipsatz in deinem Notebook.

[FlashBurn]

Das geht sogar ganz wunderbar, wenn du dich auf eine Plattform beschränkst. Du sagst "x86", meinst aber "ibmpc".

Jap, da hast du natürlich recht.

Sagen wir einfach außerhalb von "ibmpc" gibt es einfach zu viele Plattformen, die zwar eigentlich alle die gleiche Architektur verwenden, aber das wars dann auch schon. Ist aus Hobby-OS-Dever Sicht nicht so das Wahre.