Nachrichten

81

OS-Design / Re: IPC - Popup-Threads

« am: 07. January 2012, 22:50 »

Hallo,

Damit gibst du ja den großen Vorteil von Paging auf nämlich das Umgehen der Fragmentierung des physischen Speichers.

Da hast Du mich wohl miss verstanden. Ich meine nicht das der Kernel wirklich in dem 1:1 gemappten Teil selber lebt sondern der Kernel benutzt den Rest seines virtuellen Kernel-Space (deshalb darf der physische Speicher nur einen Teil des Kernel-Space belegen) so wie alle anderen Kernel auch, er nutzt nur den 1:1 Teil um darin z.B. die PDs zu manipulieren. In jedem Prozess-Descriptor benötigt man doch die physische Adresse des jeweiligen PD-Roots, die kommt ja schließlich auch ins CR3, und wenn man da einfach die statisch festgelegte virtuelle Start-Adresse des 1:1 Bereichs drauf addiert kann man das gesamte PD manipulieren wie man will (die enthaltenen physischen Adressen auf die untergeordneten Tabellen-Ebenen kann man wieder einfach mit einer Addition in eine gültige virtuelle Kernel-Space-Adresse umwandeln). Da alle Prozess-Descriptoren im normalen virtuellen Kernel-Space liegen (und damit aus jedem Kontext erreichbar sind) kann man auch immer an jedem beliebigen PD was ändern. So beliebte Tricks wie das der letzte Eintrag im Root-PD auf sich selbst zeigt damit in den letzten 4MB das PD und alle PTs enthalten sind ist damit hinfällig, dieser Trick hat ja auch wieder den Nachteil das damit immer nur das aktuelle PD manipulierbar ist.

Was Du immer mit Deinem zusammenhängen Speicher willst verstehe ich nicht. Mir fällt auf einem aktuellen PC mit einem Flat-Memory-OS absolut kein Grund ein physisch zusammenhängenden Speicher zu benötigen, nebst dessen dass das IMHO nichts mit der konzeptionellen Aufteilung des virtuellen Kernel-Space zu tun hat.


Grüße
Erik

82

OS-Design / Re: IPC - Popup-Threads

« am: 07. January 2012, 22:09 »

Hallo,


Deine Latenz ist mal wieder beängstigend kurz.

Oh, oh, dass heißt doch wiederrum das es auch nicht schlimm ist, wenn irgendein Counter in 20 Jahren mal überläuft, ist doch verschmerzbar

Nein, Du versuchst hier Äpfel mit Birnen zu vergleichen. Es ist auf jeden Fall ein Unterschied ob eine SW nach 20 Jahren Laufzeit (auf immer dem selben Computer der dann auch 20 Jahre alt ist) abstürzt oder ob ein heutiges Programm auf einen Computer der erst in 20 Jahren überhaupt gebaut werden kann nicht mehr funktioniert. Ersteres kann in einer Katastrophe enden wogegen letzteres ein normales Phänomen des technischen Fortschritts darstellt und eben grundsätzlich nicht zu einer Katastrophe führen kann weil diese unheilige Konstellation aus alter SW und neuem Computer erst gar nicht anläuft so das erst gar keine kritischen Tasks drauf laufen können. Es wäre IMHO auch ein Bug wenn ich einen heutigen Computer mit heutiger SW als tauglich teste, das ganze dann für 20 Jahre in den Schrank packe und wenn ich das irgendwann mal brauche es plötzlich nicht mehr geht. Aber eine neue Zusammenstellung muss immer erst getestet werden bevor man damit kritische Aufgaben erledigen will.

Meiner Meinung nach wäre es deutlich schlimmer wenn die alte SW auf dem neuen Computer ohne sichtbare Warnung o.ä. anläuft aber dann irgendwann einfach abstürzt weil sie mit dem neuen Computer eben doch nicht gescheit umgehen kann, da ist mir eine klare Fehlermeldung deutlich lieber, oder?

Ich wollte den Trick nutzen ....

Schon klar, aber dieser Trick kostet Dich was und da musst Du erst mal überlegen ob das Preis-Leistung-Verhältnis stimmt.

Das wäre bei deinem Konzept nicht möglich, da wäre viel mehr Aufwand für nötig.

Ja, aber bei meinem Kernel dürfte die Speicherverwaltung (vor allem weil da Dinge wie das Defragmentieren usw. mit reinspielen) die zentrale Hauptkomponente des Kernels sein so das wenn ich das austauschen wollte das ich denn eh mehr als 50% des Quell-Codes tausche und da muss ich dann ehrlich sagen das es IMHO Quatsch ist wenn der Schwanz mit dem Hund wedelt.

An was denkst du da mit mächtiger? Ich denke mal die machen das nur weil es sich bei einem Monolithen halt nicht vermeiden lässt, ansonsten wird das zu aufwändig.

So weit ich weiß ist der Heap im Linux-Kernel (also kmalloc/kfree) durchaus sehr leistungsfähig und flexibel, natürlich ist das auch ein Zwang des Monolithen weil da ja mehr als eine kleine Hand voll an verschiedenen Objekt-Größen vorkommen und die HW-Treiber ja noch mal zusätzliche Anforderungen haben (was beides bei einem Micro-Kernel nicht zutrifft).

Du bist gar nicht auf die Nachteile eines 1:1 Mappings eingegangen. Welche Vorteile bringt das eigentlich?

Der Nachteil des 1:1 Mappings ist ganz klar das man einen, im Verhältnis zum physischen Speicher, recht großen virtuellen Kernel-Space benötigt bzw. andersherum das der maximale physische Speicher signifikant kleiner sein muss als der virtuelle Kernel-Space. Der Vorteil ist das man alle PDs usw. problemlos modifizieren kann ohne irgendwelche Verrenkungen unternehmen zu müssen, alles was irgendwie in den Kernel gehört ist auch immer, von jedem Kontext aus, im Kernel-Space erreichbar. Den Teilbereich des virtuellen Kernel-Space wo der physische Speicher 1:1 gemappt wird könnte man sogar statisch festlegen so das man hier auch keine dynamischen Adressen o.ä. benötigt. Mir persönlich wäre das genug damit ich mich bei einem Flat-Memory-OS genau dafür entscheiden würde. Aber es wäre ja auch langweilig wenn jeder seine Entscheidungen so treffen würde wie ich das zu tun pflege.


Grüße
Erik

83

OS-Design / Re: IPC - Popup-Threads

« am: 07. January 2012, 21:10 »

Hallo,

Unter 32bit kommst du ja auch nicht auf die Idee bei einer 2/2 Aufteilung, bei mehr als 2GB RAM ne Fehlermeldung zu schmeißen "Too much Memory". Ne Warnung könnte ich noch im höchstfall aktzeptieren, aber ne Fehlermeldung (was für mich Abbruch bedeutet)?!

Ob Du es glaubst oder nicht, in meinem OS habe ich geplant in der 32 Bit-Version nicht mehr als 2 GB RAM zuzulassen. Mein Problem ist aber das ich in den 4 GB physischen Adressraum alles drin habe, alle Segmente aller Prozesse, der Kernel, sämtliche HW und dann brauch ich noch Reserve für den virtuellen Auslagerungsbereich wo die Segmente hin kommen wenn sie fragmentiert sind also Paging aktiv ist. Auf dem normalen x86-PC wird bei mehr als 2 GB RAM auch selten nur noch mit den Features des 386 gearbeitet, oft ist da PAE im Spiel, so das es sich streng genommen gar nicht mehr um echte 32 Bit-Systeme handelt. All diese Tricks hab ich aber nicht, ich lege einfach fest das wenn der RAM zu groß ist um vernünftig mit reinen 32 Bit-Features verwaltet zu werden dann muss eben ein 64 Bit-System her. Wenn Du Dir den Long-Mode mal genau anschaust wird Dir schnell auffallen dass das auch kein echter 64 Bit-Mode ist sondern das dort der virtuelle Adressraum auf 48 Bit (12 + 4*9) beschränkt ist. Wimre ist bei den neuesten AMD- und Intel-Prozis der physische Adressraum auf 56 Bit beschränkt (was die Fähigkeiten des Paging angeht, was also auch auf eine Art PAE hinaus läuft und auch entsprechenden Würgereiz verursacht) aber die Interfaces nach draußen können oft deutlich weniger, z.B. Hypertransport nur 40 Bit. Von daher bin ich schon der Meinung das es aus heutiger Sicht für absehbare Zeit Okay ist wenn man festlegt das der benutzte physische Adressraum maximal ein Viertel des virtuellen Kernel-Space (was ja auch nur die Hälfte des gesamten virtuellen Adressraums ist) betragen darf und sich dafür alle möglichen Krücken spart, so wie damals zu reinen 32 Bit-Zeiten. Damit kommt man mit heutigen x86-64-CPUs immerhin bis 32 TB und davon ist der Durchschnitts-PC noch einige Jahre entfernt, und wenn es mal so weit ist dann taugt das heutige OS eh nicht mehr viel so dass das Versagen dann (in > 20 Jahren) durchaus verschmerzbar ist.

Im Endeffekt ist Deine Entscheidung, Teile der Daten die eigentlich im virtuellen Kernel-Space liegen in den virtuellen Teil des jeweiligen Prozesses auszulagern, auch nur einer der möglichen Tricks um mit reinen 32 Bit-Mitteln möglichst dicht an 4 GB RAM heran zu kommen. Kann man so machen aber ich persönlich empfinde das als eher unelegant. Ich persönlich denke das auf einem Flat-Memory-System der physische RAM maximal ein Viertel des virtuellen Kernel-Space groß sein sollte damit man zuverlässig ohne Tricks auskommen kann. Dein Trick hat den Nachteil das Du nicht mehr im Kontext eines beliebigen Prozesses in der Verwaltung des virtuellen Adressraum eines anderen beliebigen Prozesses was ändern kannst, andere Tricks haben andere Nachteile, daher meine generelle Ablehnung solcher Tricks.

Kann sein das wir aneinander vorbei geredet haben

Oh ja, es ging doch eigentlich darum das Du eine austauschbare Speicherverwaltung für Deinen Micro-Kernel möchtest und ich der Meinung bin das die Speicherverwaltung in einem Micro-Kernel so zentral ist dass das Austauschen keinen Sinn ergibt. Klar muss man bestimmte Dinge hinter einem HAL verstecken wenn das OS auf wirklich verschiedenen CPU-Architekturen laufen soll aber das ist doch gar nicht das Thema dieser Teil-Diskussion gewesen.

Ich bin mir nicht mehr sicher, aber der Linux-Kernel macht sowas in der Art (Software-Emulation der Paging-Hierarchie) und da bin ich absolut dagegen. Die "paar" Zeilen Code kann man ruhig richtig auf die Hardware anpassen.

Ich denke mit was anderem als einer Software-Abstraktion bekommt man so unterschiedliche CPU-Architekturen (was die konkrete Implementierung des Paging angeht) wie x86, x86-64, ARM und SPARC kaum unter einen Hut und da die Speicherverwaltung des Linux-Kernel deutlich mächtiger und umfangreicher als die eines typischen Micro-Kernel ist lohnt es sich IMHO durchaus da passend zu abstrahieren um die Speicherverwaltung immer gleich lassen zu können.


Grüße
Erik

84

OS-Design / Re: IPC - Popup-Threads

« am: 07. January 2012, 14:48 »

Hallo,

Doch, hast du weiter unten sogar gequotet Der ist ca. 8MB oder so groß ...

Aha, da hab ich wohl den Zusammenhang aus den Augen verloren, sorry.

und er ist statisch zwecks Henne-Ei-Problem bzw. Kreis-Abhängigkeiten!

Gut, das mit dem statisch kann ich zwar verstehen und nachvollziehen (Henne-Ei-Probleme und Kreis-Abhängigkeiten sind eklig) aber ist meiner persönlichen Meinung nach trotzdem ein wenig Verschwendung. Aber es ist Deine Design-Entscheidung und gut.

Sorry, aber das wiederspricht sich mMn ja "alle Eventualitäten denken" und "Fehlermeldung "To much Memory"".

Wo widerspricht sich das? Ich als Programmierer denke an die Eventualität das auch mal mehr physischer RAM im System sein könnte als mit dem im OS-Kernel implementierten Mechanismus sinnvoll verwaltet werden kann und deswegen fange ich das ab und gebe eine aussagekräftige Fehlermeldung. Ich denke das ist genau das was ich meine wenn ich sage das man als Programmierer auch mit ungewöhnlichen/unerwarteten/unmöglichen Randfällen umgehen sollte. Die maximale Menge an physischen Adressraum ist ja nichts was sich dynamisch zur Laufzeit ändert (deswegen muss man das auch nicht wie einen theoretisch überlaufenden Counter zur Laufzeit handhaben) sondern steht zur Boot-Zeit fest und das OS kann mit einer einzelnen Abfrage hier auf Nummer sicher gehen. An der selben Stelle im Boot-Code sollte auch noch eine Abfrage sein ob mindestens X MBytes an physischen RAM vorhanden sind damit das OS nicht schon beim Booten abstürzt.

Zumal du dann wieder genau das gleiche Problem wie der Linux-Kernel hast (und genau das will ich auch nicht). Du hast 64MB frei, brauchst 128KB, aber der größte zusammenhängende Bereich ist nur 64KB groß!

Hä, was meinst Du? Was hat die konkrete interne Speicherverwaltung im OS-Kernel damit zu tun wenn das OS beim Start prüft ob die Größe des benutzten physischen Adressraums für das OS im grünen Bereich liegt?

Ich würde/werde für jede Architektur nen anderen HAL schreiben.

Willst Du damit sagen das Deiner Meinung nach die Speicherverwaltung des OS-Kernels in den HAL gehört? Das erscheint mir persönlich doch etwas arg seltsam. Ich kenne im Embedded-Umfeld einige OSe die auf mehr als 10 verschiedenen CPU-Architekturen laufen und diese CPU-Architekturen haben oft nicht viel mehr gemeinsam als das der virtuelle Speicher mit Hilfe von klassischem Paging gemanaged wird. Wie z.B. die PT-Einträge aufgebaut sind oder wie groß die Pages sind kann sich unterschieden aber das wird nur mit einer CPU-Architektur-spezifischen .h-Datei geregelt und ansonsten ist der Code für die Speicherverwaltung immer der selbe. Die Basis-Mechanismen von Flat-Memory (also die Wirkungsweise von Paging) sind auf allen real existierenden CPUs so enorm ähnlich das es sich einfach nicht lohnt dafür unterschiedlichen Code zu schreiben. Es ist doch auch relativ egal ob die Pages 4kB oder 8kB groß sind oder ob ein x-stufiges Paging-Directory in Hardware benutzt wird oder ob das per SW emuliert wird.


Grüße
Erik

85

OS-Design / Re: Optimale Baumstrukturen fuer malloc/free

« am: 07. January 2012, 14:07 »

Hallo,

Kannst du das konkretisieren? Was ist "professioneller Einsatz"?

Lass es mich so formulieren: Jemand der seine CPU übertaktet zieht Performance der Reliabiliy vor.

Das ist zwar richtig aber keine Antwort auf die Frage.


Grüße
Erik

86

OS-Design / Re: Optimale Baumstrukturen fuer malloc/free

« am: 06. January 2012, 20:56 »

Hallo,


sorry wenn ich das so direkt schreibe aber ich finde Du übertreibst ein ganz klein wenig.
Gerade im professionellen Umfeld ist Zeit oft gleich Geld und damit spielt dort Performance eine sehr wichtige Rolle. Ich hab z.B. beruflich (und auch privat) sehr viel mit FPGA-Programmierung zu tun und ein kompletter Synthese-Durchlauf kann da schon mal ne Stunde dauern und viele Simulationen (die oft nur wenige µs an Real-Zeit simulieren) laufen mehrere Stunden bis ein Ergebnis vorliegt. Aus diesem Grund hatte ich bei diesen Tätigkeiten immer einen Top-PC vor der Nase zu stehen, einfach weil ein paar Stunden Untätigkeit teurer sind als der PC. Wegen der Wichtigkeit der erzeugten Ergebnisse waren diese PCs auch immer mit ECC-tauglichem Speicher und Chipsatz ausgestattet, auch wenn das wieder einen Teil der Performance gekostet hat (ECC verursacht beim Speicherzugriff immer ein paar Takte zusätzliche Latenz).

Ich persönlich hab es noch nicht erlebt das eine ordentlich betriebene CPU (ohne Übertaktung und mit angemessener Kühlung auf einen anständigen Main-Board mit adäquater Energieversorgung) sich mal verrechnet hätte (ja ich weiß es gab da mal den FDIV-Bug in einigen Pentiums aber so eine CPU hatte ich nie benutzt) von daher erachte ich die Investition in einen guten Work-Station-PC als ausreichend. Nebst dessen das jedes FPGA-Image immer erst gründlich getestet wird bevor es ausgeliefert wird.


Grüße
Erik

87

OS-Design / Re: IPC - Popup-Threads

« am: 06. January 2012, 20:41 »

Hallo,


da momentan das Aufwärmen alter Threads gerade Mode ist will ich hier noch mal ansetzen.

Da habe ich dann mal wieder zu wenig Infos preisgegeben.

Ja. Du hast z.B. immer noch nicht angegeben wie groß der Bereich, den Dein Mini-Allocator verwaltet, eigentlich ist. Zum anderen halte ich es auch nicht für sinnvoll das statisch festzulegen, dieser Speicher ist dann für andere Zwecke verloren.
Wenn ich Dich richtig verstanden habe willst Du darin die Verwaltungsdaten für den Kernel-Heap unterbringen, richtig?

aber ich muss nicht Buch führen wie groß der freie Bereich ist oder ob noch genug frei ist, weil der Bereich der verwaltet wird groß genug für den worst-case ist (plus ein wenig mehr, um ein vernünftiges Alignment zu bekommen).

Also das erscheint mir etwas zu magisch, zumindest musst Du wissen wo Du neue Pages hinmappen kannst und Du solltest auch noch zumindest einen einfachen Integerwert haben der Dir sagt wie viel noch frei ist.

Dieser Allocator ist ein sehr vereinfachter SlabAllocator, halt nur ohne die große dynamische Verwaltung. Im Endeffekt könnte man sagen, dass ist das was du mir die ganze Zeit vorschlägst nur für nen ganz kleinen statisch festgelegten Bereich.

Nein, was ich verschlage ist den bereits vorhanden SLAB-Allocator für alles zu nutzen und nicht noch einen zusätzlichen (wenn auch primitiven) dazu zubauen.

Wenn ich Dich richtig verstanden habe willst Du doch das oberste GB des virtuellen Adressraums dem Kernel geben, das zweitoberste GB ist dann Prozess-lokal aber trotzdem nur für den Kernel zugänglich und der Prozess bekommt dann die unteren 2 GB.

Jetzt könnte ich auch schreiben, dass du mich einfach nicht verstehen willst Ich habe eine 3/1 Aufteilung, also 3GB Prozess und 1GB Kernel.

Du hast bisher gar keine konkreten Informationen über das Layout Deines virtuellen Adressraums gegeben, mit "Wenn ich Dich richtig verstanden habe" hab ich doch klar ausgedrückt das ich nur spekuliere.

Es gibt allerdings im KernelSpace noch einen kleinen (8MB oder so) Prozess-lokalen Bereich für den User-VMM.

Das heist dieser Bereich gehört noch zu dem oberen 1 GB aber es gibt dort für jeden Prozess individuelle PTs (also in jedem Prozess ist dort anderer physischer Speicher eingebunden)?

Du bist doch immer der, der meint das man auch einen Counter der erst in über 100Jahren überläuft so programmieren sollte, das man mit dem Fall umgehen kann. Aber du willst den physischen Speicher 1:1 mappen?

Ja, ich bin der Meinung das man an möglichst alle Eventualitäten denken sollte und genau deswegen würde ich in den Start-Code des Kernels eine Abfrage einbauen die prüft ob der tatsächlich benutzte physische Adressraum klein genug ist um in den virtuellen Adressraum des Kernels komplett und bequem rein zu passen ansonsten gibt es eine Fehlermeldung "To much Memory".

Das :

Zumal ich mir halt so die Möglichkeit offen halte, einfach den Allocator austauschen zu können.

und das :

Ist es sehr schlecht wenn ich dir jetzt sage, dass das genau meine Meinung bei einem MikroKernel ist Der Kernel ist doch wirklich nicht so groß und da sollte man zusehen, dass man das beste aus der Architektur rausholt.

widerspricht sich irgendwie. Auf der einen Seite möchtest Du möglichst viel Flexibilität und auf der anderen willst Du die Meinung vertreten das ein Micro-Kernel ruhig möglichst aus einem Guss sein soll, ich bin verwirrt.

Zumal ich kein Fan von den ganzen Präprozessor if´s, die es insbesondere im Linux-Kernel, aber auch in den meisten libc´s gibt.

Diese Einstellung findet meine uneingeschränkte Zustimmung.

mir gefällt es besser wenn diese Ebenen der Speicherverwaltung durch klar definierte Interfaces getrennt sind.

Dann musst Du aber auch alle indirekten Nebeneffekte mit berücksichtigen in Deiner Interface-Beschreibung (die zu diesem Zweck wirklich schriftlich erfolgen sollte damit Du auch in Jahren möglichst kein Detail aus den Augen verlierst). Ich hab bei mir z.B. mit beschrieben welche Locks frei sein müssen wenn bestimmte Funktionen mit bestimmten Parametern aufgerufen werden.


Grüße
Erik

88

OS-Design / Re: GUI LowLevel

« am: 06. January 2012, 20:06 »

Hallo,

Du sprichst also vom fertigen Code, der dann auf der GPU läuft? An den komme ich per WebGL doch gar nicht ran.

Ja. Ist doch egal, es gibt Wege und das reicht. Und wer richtigen Schadcode erstellen will wird sicher nicht den Compiler im Treiber benutzen sondern andere/eigene Wege finden.

Die Hersteller der GPUs sind auf jeden Fall sehr daran interessiert sich von den Wettbewerbern durch spezielle Features abzuheben (was ansich ja auch völlig legitim ist und zu jeder gesunden Marktwirtschaft dazugehört), damit die Programme diese Features aber auch nutzen können müssen sie den genauen Typ der vorhandenen GPU identifizieren können und das wird sicher auch bei WebGL gehen. Damit wird aber auch die Möglichkeit eröffnet GPU-spezifische Shader-Programme zu laden und die dürften im Interesse schneller Start-Zeiten und kurzer Download-Zeiten bereits vorkompiliert sein. Bis hier ist alles so wie von den GPU-Herstellern und von den Anwendungsentwicklern gewünscht nur leider profitieren davon auch die Schadcode-Programmierer, wenn Du da eine gute Idee hast wie die ersten Gruppen trotzdem zu ihren Zielen kommen und gleichzeitig die letzte Gruppe ausgeschlossen wird so wird man Deine Ideen sicher berücksichtigen ansonsten gehe ich davon aus das die WebGL-Designer eben dieses Risiko einfach eingehen werden und die Anwender werden es früher oder später auch müssen wenn sie nicht vom graphischen Schnick-Schnack im Web komplett ausgeschlossen werden wollen.

OT: Gibt es ein standardisiertes Protokoll zur Kommunikation mit OpenGL-Hardware?

Nein. Und es gibt auch keine "OpenGL-Hardware", es gibt höchstens GPUs mit deren Features es möglich ist einen OpenGL-konformen Treiber zu entwickeln. OpenGL beschreibt wimre nur eine High-Level-API (das Interface zwischen Treiber und Applikation) und eben die Funktionalitäten die damit verfügbar gemacht werden sollen.


Grüße
Erik

89

OS-Design / Re: Optimale Baumstrukturen fuer malloc/free

« am: 06. January 2012, 19:52 »

Hallo,

Man sollte meiner Ansicht nach immer mit einem Fehler oder Defekt der Hardware rechnen und die Auswirkungen minimieren.

Das würde ich persönlich nur dann bejahen wenn Performance eine höhere Priorität hat, als SW-Entwickler sollte man IMHO die HW als Fehlerfrei ansehen dürfen. Wenn man z.B. mit Problemen im RAM rechnet dann gibt es ECC, aber gegen ein falsches Rechenergebnis in der CPU kann man nichts unternehmen. Bei Dingen wo es wirklich drauf ankommt (Medizin oder Raumfahrt) werden einfach ganze Systeme mehrfach aufgebaut und redundant betrieben.

Ein Dateisystem sollte sich meiner persönlichen Meinung nach auch keine Gedanken über defekte Sektoren machen sondern das Block-Device einfach als riesiges Array betrachten und fertig, wenn defekte Sektoren nich zum Problem werden dürfen dann gibt es RAID und wenn die Daten "Mission-Critical" sind dann liegen sie mit guten Prüfsummen abgesichert auf mehreren unabhängigen System an verschiedenen Orten.

Ich habe nichts dagegen wenn auch der SW-Entwickler sich Gedanken über HW-Sicherheit macht, hier ist Redundanz immer gut, aber es ist IMHO nicht seine vordringlichste Aufgabe. Wenn ich mich zwischen Performance und Robustheit gegen HW-Fehler entscheiden muss nehme ich immer Performance.


Grüße
Erik

90

OS-Design / Re: GUI LowLevel

« am: 05. January 2012, 22:19 »

Hallo,


das Problem sind nicht die Programme in den High-Level-Shader-Sprachen die für generische abstrakte Shader entwickelt werden sondern der fertig kompilierte Objekt-Code der von den realen Shadern ausgeführt wird. Dort gibt es meines Wissen nach echte 64Bit-Pointer in den modernen Shadern (sowohl bei AMD, NVidea als auch bei Intel). Die GPUs haben auch eine Art MMU, mit der ganz gewöhnliches Paging gemacht wird, damit die Texturen und sonstigen Daten die ja verstreut im physischen RAM liegen zusammenhängend benutzt werden können, die GPUs haben quasi eine eigene virtualisierte Sicht auf den RAM. Deswegen macht es auch theoretisch nichts aus ob Texturen u.ä. wirklich im lokalen GPU-RAM oder nur im normalen Haupt-RAM liegen, von der Performance mal abgesehen. In den Treibern wird wohl keine Sicherheitsüberprüfung des Shader-Objekt-Code stattfinden, dazu müsste dort eine recht umfangreiche Code- und Daten-Flussanalyse durchgeführt werden um feststellen zu können ob irgend ein Pointer nicht doch mal auf Speicherbereiche zeigt die eigentlich nicht gewünscht sind. Spätestens wenn die Shader-Programme in der Lage sind Texturen u.ä. zur Laufzeit von der SW flexibel zur Verfügung gestellt zu bekommen ist auch das nicht mehr sinnvoll möglich.
Es gibt also sehr viele Punkte an denen man ansetzen könnte um mit Hilfe der GPU den normalen RAM zu manipulieren, z.B. einfach nur das GPU-Paging zu verbiegen um anderen physischen Speicher anzusprechen. Ich wette hier stecken die Viren-Programmierer noch in der sehr frühen Konzeptionierungsphase, aber sollte WebGL wirklich so kommen wie derzeit beabsichtigt dann dürfte das ein neues lukratives und sicher auch interessantes Betätigungsfeld für die Viren-Programmierer und deren Kontrahenten bei den AV-SW-Herstellern werden. Ich gehe davon aus das die Einführung von WebGL in erster Linie der Aufrechterhaltung der Einnahmequellen der AV-SW-Hersteller dient.

Bezüglich DMA ging ich bisher davon aus, dass bestimmte Bereiche im RAM gemappt werden.

Wie bzw. durch welche HW-Komponente soll das den passieren? Ohne eine IOMMU hat jede busmasterfähige HW vollen Zugriff auf den gesamten physischen Adressraum, sogar auf andere HW-Komponenten (falls der Chipsatz das unterstützt, in der PCI-Spec steht dazu "implementierungsspezifisch"). Das trifft übrigens nicht nur auf PCI und seine Erben zu sondern gilt auch für EISA, VLB u.a.m. Das einzigste was wirklich hilft ist eine gute IOMMU die direkt im Chipsatz steckt und jeden Zugriff der von der Peripherie-HW kommt filtert und nur vom OS-Kernel kontrolliert wird.

Falls das zutrifft könnte man Speicherschutz mit Segmenten erreichen.

Sowas traust Du Dich vorzuschlagen? Respekt! Die bösen Segmente will doch heute niemand mehr haben. Die waren schließlich zu DOS-Zeiten ein Quell grenzenloser Freude.

Abgesehen davon bin ich nicht sehr glücklich darüber, dass die Ingenieure von PC-Hardware davon auszugehen scheinen, dass Bedrohungen für ein System ausschließlich durch Software bestehen und folglich den Hardware-Komponenten eines Systems bedingungslos vertrauen.

Willkommen in der Realität! Dieses bedingungslose Vertrauen erstreckt sich übrigens auch auf die Treiber, mit der passenden Konfiguration kann jede busmasterfähige HW eine echte Bedrohung werden (falls dem nicht eine IOMMU Einhalt gebietet, aber die wird vom OS-Kernel sicher auch nur anhand der Wünsche der potentiell fehlerhaften Treiber konfiguriert, wenn Du Dir jetzt mal mein IPC-Konzept anschaust wirst Du vielleicht feststellen das Segmente hier einiges zu bieten haben). Wenn Du die Bedrohungen durch Firewire kennst und Dir überlegst was ein vollwertiger PCI-Express-Link nach draußen erst alles anstellen kann dann dürfte es Dir sicher auch schwer fallen die Idee von Thunderbolt zu verstehen.


Grüße
Erik

91

Offtopic / Re: [erledigt] Komisches Problem ...

« am: 05. January 2012, 19:28 »

Hallo,

wobei es noch besser wäre wenn EAGLE das automatisch machen würde ...

Genau das ist es was mich wundert, ich musste das bis her in keinem Layout-Programm extra konfigurieren, das war immer in den Default-Foot-Prints der Bibliotheken schon so drin. Nur wenn ich komplett eigene Foot-Prints erstellt habe, ohne irgendeinen automatischen Generator, musste ich das Pin 1 extra behandeln ansonsten war das immer schon von Haus aus erledigt. Ich denke mal das mir das gerade deswegen auch nicht in Deinen Layouts aufgefallen ist weil ich bei diesem Detail einfach nicht auf die Idee gekommen bin das man da drauf achten muss.

Ich würde mich an Deiner Stelle mal in einem Elektroniker-Forum (z.B. auf µC.net) umhören ob jemand anders ähnliche Erfahrungen mit EAGLE gemacht hat und eine passende Lösung kennt.
Ist den wenigstens der Bestückungsdruck in Ordnung?

Auch wenn ich noch nicht explizit drauf eingegangen bin so finde ich Deine Fortschrittsberichte auf jeden Fall interessant und würde mich freuen wenn die weiterhin ab und an mal kommen.


Grüße
Erik

92

Offtopic / Re: [erledigt] Komisches Problem ...

« am: 04. January 2012, 19:10 »

Hallo,

Der Aufbau der Platine hat etwas länger gedauert weil ich den MAX232 und den L6202 falsch herum eingebaut/-gelötet habe  .

Hm, ungeschickt.

Ich werde mir angewöhnen alle Chips immer in die gleiche Richtung auszurichten, dann passiert sowas nicht nochmal - so hab ich es nämlich eingebaut/-gelötet.

Davon würde ich abraten, das verursacht oft ein ungünstiges Routing der Signale. Du solltest Dir lieber den Bestücktungsdruck auf Papier ausdrucken und neben den Lötarbeitsplatz legen.
Ansonsten hab ich gerade noch mal auf Dein Platinenlayout geschaut und mir ist aufgefallen das bei den DIP-Gehäusen gar nicht das Pin 1 rechteckig ist sondern auch immer abgerundet. Ich bin es gewöhnt dass das Pin 1 auch auf der Platine immer etwas anders aussieht als der Rest, selbst bei TQFP-Behausungen usw., nur BGA-Behausungen sind da wimre eine Ausnahme. Sorry, das ich das bei der Platinenkontrolle übersehen hab, aber wie so oft sind es die einfachen banalen Dinge die einem entgehen.


Vielleicht kannst Du ja noch ein Video mit dem sich bewegenden Auto hochladen.


Grüße
Erik

93

Offtopic / Re: Eigene CPU

« am: 04. January 2012, 18:58 »

Hallo,

OK, bin jetzt vom Idealfall ausgegangen

Auch dann wird für ein Objekt mit 21 Bytes sicher mehr als das benötigt, also Verwaltungsinformationen kommen in jedem Fall dazu.

Ansonsten fällt mir gerade ein das bei CPUs die keine unausgerichteten Speicherzugriffe unterstützen, was auf fast alle außer x86 zutrifft, der Pointer der von malloc kommt eigentlich zwangsläufig mindestens auf den größten nativ von der CPU unterstützten Datentyp ausgerichtet sein muss da ansonsten der Compiler gar keinen validen Code erzeugen kann. In einer Struktur werden auf solchen CPUs auch alle Member auf ihre Größe entsprechend ausgerichtet. Aber für x86 ist es auf jeden Fall möglich (wenn auch unperformant) komplett ohne Alignment und Padding auszukommen.


Grüße
Erik

94

Offtopic / Re: Eigene CPU

« am: 04. January 2012, 03:48 »

Hallo,


für malloc/free ist nicht das OS zuständig sondern die libc innerhalb der Applikation, also Teil des User-Mode-Codes. Mit malloc/free wird der Heap benutzt und wie dieser intern verwaltet wird ist je nach Realisierung der libc ziemlich unterschiedlich. Da gibt es von ganz simplen verketteten Listen bis hin zu komplexen SLAB-Allocatoren eine ordentlich große Bandbreite ab Möglichkeiten. Letztlich bauen diese aber alle auf den normalen virtuellen Speicher auf den die Applikation vom OS bekommt, zumindest auf einem normalen Flat-Memory-System. In diesem Punkt unterschieden sich Windows und Linux (und auch alle anderen OSe in dieser Klasse) nur marginal von einander.

Was alle aktuellen OSe gemeinsam haben ist die Art mit der sie den virtuellen Speicher den Applikationen zur Verfügung stellen also das Paging, was eben der Grundstein des Flat-Memory-Konzepts darstellt. Paging ist zwar eine tolle Idee aber hat einen erheblichen Nachteil: es kostet bei jedem Speicherzugriff Performance. Das wird zwar mit Dingen wie dem TLB noch einigermaßen gut abgefangen aber spätestens wenn reale Programme mal wirklich ein paar TB an echtem Speicher benötigen und auch benutzen wollen dürfte das Konzept des TLB an seine Grenzen geraten sein und der Performanceverlust fürs Paging enorm werden. Deswegen möchte ich das mit Segmenten machen, die kosten deutlich weniger Performance und das ist auch nicht davon abhängig wie viele Segmente ein Programm insgesamt nutzt oder wie groß diese Segmente sind. Das einzigste was passen muss ist die Anzahl der Segment-Register (wovon x86 leider viel zu wenige hat so das dort Segmentierung nie wirklich zufriedenstellend war, nebst dessen das Segmentierung bei x86 auch nur schlecht im Befehlssatz integriert ist).

Für meine Heap-Implementierung, innerhalb der libc, will ich auch ein paar Segmente benutzen (die per Syscall vom OS geholt und verwaltet werden). Ich denke das ich es schaffe damit eine recht kleine innere Fragmentierung zu erreichen aber dafür habe ich das Risiko einer externen Fragmentierung also die einzelnen Segmente werden den physischen Speicher langsam fragmentieren (wie die Dateien auf einer Festplatte). Vor allem wenn die Speichernutzung sich langsam der Größe des physischen Speichers nähert wird das ein dringenderes Problem. Deswegen möchte ich die Möglichkeit haben für einzelne Segmente individuell Paging aktivieren zu können. Auf diese Art bleibt das Segment aus Sicht der Applikation intakt obwohl es über den physischen Speicher verstreut also fragmentiert ist. Das Paging ermöglicht es dann auch dieses Segment im Hintergrund, also ohne das die Applikation das merkt (vom Performanceverlust mal abgesehen), zu defragmentieren. Sobald das Defragmentieren der Segmente im physischen Speicher abgeschlossen ist kann das Paging wieder deaktiviert werden und die betreffende Applikation läuft wieder mit voller Performance.

Mir ist bewusst das ich mir damit einiges an Problemen aufhalse (z.B. was passiert wenn ein Segment vergrößert werden soll während es defragmentiert wird? gerade in einem SMP-System kann ja theoretisch beides gleichzeitig passieren) aber ich denke das sich das unterm Strich trotzdem lohnt. In den modernen Flat-Memory-OSen versucht man ja auch eine Art Defragmentierung einzubauen damit z.B. viele 4kB-Pages zu einer 2MB-Page zusammengefasst werden können, mit steigendem realen Speicherverbrauch der Applikationen wird das auch immer nötiger werden um den Performanceverlust durchs Paging in Grenzen zu halten.

Für mein System betrachte ich Paging nicht als Mittel gegen Fragmentierung, die wird bei meinen Segmenten zwangsläufig auftreten, sondern eher als Werkzeug um diese Fragmentierung wieder zu beheben. Auch fürs Swapping ist IMHO Paging die einzigst praktikable Lösung. Daneben eröffnet mir das Paging auch Dinge wie Memory-Mapped-File-IO aber das kommt erst sehr viel später dran. Im übrigen werden bei mir Segmente auch immer nur ganze Pages belegen und in jeder Page wird immer nur maximal ein Segment drin sein, so ähnlich wie ein Cluser bei FAT auch immer nur von einer Datei benutzt werden kann. Die Verwaltung des physischen Speichers in meinem OS wird also auch nur mit Pages arbeiten. Der wesentliche Unterschied zwischen Segmentierung und Paging ist der das für Segmentierung eine Basis und eine Größenangabe reicht um jedes Offset das innerhalb des Segments liegt in eine physische Adresse umrechnen zu können wogegen bei Paging riesige Tabellen erforderlich sind um eine virtuelle Adresse in eine physische Adresse umwandeln zu können.

In normalen Programmiersprachen, wie z.B. C, sind lokale Variablen (innerhalb von Funktionen) immer auf dem Stack und nicht auf dem Heap. Bei Java landet alles auf dem Heap, ist dort ein wesentlicher Aspekt des Gesamtkonzepts, und man kann als Programmierer auch nicht explizit zwischen Heap und Stack wählen aber bei vielen anderen Programmiersprachen wird zwischen Heap und Stack klar unterschieden und der Programmierer hat auch die Wahl was er benutzen möchte. Ich vermute Du solltest Dir einfach mal noch ein paar andere Dinge abseits von Java genauer ansehen um einen besseren Überblick über die vielfältigen Möglichkeiten zu bekommen.


Grüße
Erik

95

OS-Design / Re: Wie geht ihr an die Entwicklung eures OS heran?

« am: 24. December 2011, 10:13 »

Hallo,

Du kannst für etwas, von dem du noch keine Ahnung hast, keine gute Planung machen.

Meine Berufspraxis sagt mir da was anderes, ich hab noch nie ein Projekt bekommen bei dem ich schon vorher die volle Ahnung hatte sondern es lief immer auf "learning by doing" hinaus. Beim Top-Down-Ansatz wird man dann früher oder später auf einen Punkt stoßen an dem einem das nötige Wissen fehlt und dann muss man sich dieses eben besorgen.

Aber Thema hatten wir schon öfter.

Stimmt auffallend, ebenso wie die Tatsache das wir hier wohl nie eine eindeutige Antwort auf dieses Thema finden werden. Vielleicht sollten wir zukünftig derartige Fragen mit einem freundlichen Hinweis auf die Suchfunktion beantworten.


Ich wünsche Euch allen fröhliche Weihnachten
Erik

96

OS-Design / Re: Wie geht ihr an die Entwicklung eures OS heran?

« am: 23. December 2011, 22:18 »

Hallo,


ich persönlich bevorzuge TOP-DOWN. Ich entwickle erst mal eine grobe Idee was ich eigentlich erreichen möchte, danach zerlege ich die sich ergebenen Probleme in ihre Teile und fange dann für jedes einzelne Teil-Problem von vorne an. Das klingt aufwendig und das ist es auch aber es ist IMHO die einzigste Methode mit der man wirklich ein gutes Ergebnis erreichen kann. Für einzelne Module macht das im Prinzip jeder so, man überlegt sich was soll dieses Modul machen und dann überlegt man sich wie man diese Aufgabenstellung in Funktionen und letztendlich in einzelne Anweisungen zerlegen kann. Das Problem dabei ist eher das die so gebauten Module insich zwar oft einigermaßen korrekt sind aber nicht immer mit den anderen Modulen anständig zusammenspielen, das kommt daher das beim Entwurf des Moduls selber eben keine von oben gekommenen Design-Ziele zur Verfügung standen so das diese Module dann eben nicht richtig zusammenpassen.
Auf jeden Fall kostet eine sauber strukturierte Vorgehensweise einiges an Disziplin und Zeit aber ich behaupte das man mit der chaotischen Variante, erst mal Code tippen und dann hinterher herausfinden was nicht stimmt, für das selbe Ergebnis in Summe mehr Zeit aufwenden muss (wegen den vielen Fehlschlägen) und letztendlich doch von oben nach unten plant (nur merkt man das dann nicht so deutlich weil es iterativ und eben als chaotischer Prozess passiert).

Ich bin mir sicher das hier bestimmt etliche Leute glauben das ich nicht mal aufs Klo gehe ohne mir vorher einen wirklich gut durchdachten Plan zurecht zu legen (ob das die Wahrheit ist werde ich nicht kommentieren), aber ich bleibe trotzdem bei der Meinung das eine gute Planung die Erfolgsaussichten eines jeden Projekts (das mehr als 10 Stunden Zeitbedarf beinhaltet) signifikant steigert.

Jedes Einzelteil auf Anhieb fehlerfrei hinzubekommen, ist unmöglich.

Kannst Du das beweisen?


Grüße
Erik


PS.: von einem eigenen Boot-Loader würde ich auch nur dann nicht abraten wenn Dich Deine masochistische Ader unbedingt zwingt Dir so tolle Dinge wie den x86-Real-Mode anzutun. Wenn ich näher darüber nachdenke komme ich zu dem Schluss dass das Programmieren eines OS für die x86-Plattform grundsätzlich eine ausgeprägte masochistische Ader erfordert, aber ich vermute das hier auch ziemlich viele Leute ähnlich über Segmentierung denken.

97

Lowlevel-Coding / Re: GAS: ASCII-Strings (für INT10/13h) in ASM-Programm einbinden

« am: 23. December 2011, 21:24 »

Hallo,


ich bin mir jetzt nicht ganz sicher was Du meinst aber wenn Du Deine Strings als Binär-Daten in Dateien vorrätig hast dann kannst Du diese eventuell mit 'BIN2H' in eine Header-Datei umwandeln lassen um das ganze beim make-Prozess zu automatisieren. So eine Header-Datei enthält dann immer ein char-Array mit der Art : const char NAME[] = { 0x41 , 0x42 , 0x43 , 0x00 }; Dazu kommt dann noch ein Define das Dir die Größe des Array verrät.

Wenn ich Deine Frage auch nicht richtig verstanden haben sollte wäre es gut wenn Du diese etwas präzisieren könntest.


Grüße
Erik

98

Lowlevel-Coding / Re: Bochs: Eigenes Bootsektorscript "Not a bootable disk"

« am: 15. December 2011, 21:23 »

Hallo,


Ich gehe mal davon aus das Deine Disketten Sektoren mit 512 Bytes haben:

.org   512*8-2

Ich schätze das muss gegen ".org 512-2" ohne das "*8" ersetzt werden.

0ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 aa 55

Dann dürfte auch hier die Adresse 01f0 stehen.


Grüße
Erik

99

Offtopic / Re: [erledigt] Komisches Problem ...

« am: 15. December 2011, 18:48 »

Hallo,

Also ist FRAM Flash RAM

<klugscheiß>Nein, das heißt Ferroelectric Random Access Memory (siehe http://ramtron.com/files/tech_papers/FerroelectricTechBrief.pdf) und hat mit FLASH gar nix zu tun</klugscheiß>

das Display ist mit 100.000 Stunden angegeben. Angesichts des Preises wird es aber doch ein LCD werden.

Das mit der Lebensdauer wundert mich ehrlich gesagt etwas, aber das der Preis das relevante Kriterium ist ist verständlich.


Grüße
Erik

100

Offtopic / Re: [erledigt] Komisches Problem ...

« am: 15. December 2011, 09:52 »

Hallo,

FRAM?

Is ne Kreuzung aus EEPROM und SRAM, aber es wurden nur die jeweiligen Stärken kombiniert und die Schwächen beseitigt. Der ist so schnell und beliebig zugreifbar wie SRAM (gilt beides für Lesen und Schreiben) aber behält seine Daten auch ohne externe Energieversorgung wie ein EEPROM. Siehe ramtron.com/.

Gibt das mit der Firma keine (rechtlichen) Probleme?

Nö. Welche den auch? Man muss halt nur aufpassen das man keine unpassenden Verträge abschließt. Ich hab kein Gewerbe angemeldet und auch keine Umsatz-Steuer-ID, meine Firma ist also eine klassische Briefkastenfirma. Und mit SPAM meine ich die vielen Elektronik-Zeitschriften und sonstigen Broschüren von Messe-Veranstaltern usw, eben von all denen wo ich schon als Firma aufgetreten bin.

Die Platine ist inzwischen fertig, wurde heute ausgeliefert.

Dann viel Vergnügen und eine oder besser zwei ruhige Hände beim Löten.


Von OLED würde ich persönlich auch eher abraten, ich hab da viel schlechtes über deren Lebenserwartung gelesen. Für Display wird als Lebenserwartung meistens die ununterbrochene Betriebsdauer gemeint die vergeht bis nur noch 50% (in speziellen Anwendungsbereichen auch 60%-70%) der ursprünglichen Helligkeit erreicht werden und eine kleine LED-basierte Hintergrundbeleuchtung kann da durchaus 50000 Stunden (und mehr) erreichen wogegen bezahlbare OLEDs noch nicht mal 10000 Stunden erreichen. Klar ist das immer noch ein etwa ganzes Jahr im 24/7-Betrieb, den Du ja wohl kaum haben wirst, aber wenn Du an Deinem Spielzeug länger Freude haben möchtest und vielleicht das Display später noch mal wo anders einsetzen willst dann würde ich persönlich eher kein OLED empfehlen. In Handy gehen die Hersteller diesen Kompromiss ein weil die davon ausgehen das der Kunde das Handy eh nach spätestens 3 Jahren ersetzt und ein Second-Hand-Markt für Handys ich bei den Herstellern auch nicht gern gesehen so das man da schon fast Absicht unterstellen kann das so ein Handy nicht länger als 3 Jahre hallten soll.
Wenn Du die Hintergrundbeleuchtung schaltbar (und eventuell dimmbar) machst dürfte auch der Stromverbrauch keine so große Rolle spielen, da sind IMHO auf Deiner Platine auch noch andere Komponenten mit erheblichen Einsparpotential.


@Svenska: noch mal über meine Erklärung vom Sonntag, wegen den Problemen der Taktverteilung, nachgedacht?


Grüße
Erik