Nachrichten

661

Lowlevel-Coding / Re:Treiber "Management"

« am: 22. September 2010, 19:15 »

Schön wäre es wenn man zumindest bei externen Zugriffen auf den normalen RAM in Chipsatz ein paar Sperren hätte so das der Kernel wenigstens sich selber (und vielleicht noch Pages die die Applikationen als besonders sensibel markiert haben weil z.B. Passwörter drin liegen) schützen könnte.

Ich würde mir ne andere Variante als besser vorstellen. Nämlich ungefähr so wie bei ISA DMA, sprich wie DMA programmiert wird ist bekannt und bei allen Sachen gleich, sprich es ist im Standard drin (vielleicht ein extra Register im PCI CfgSpace). Dies ist natürlich für den gleichzeitigen Zugriff mehrerer Geräte ungünstig, aber das könnte man so lösen, das man halt nen Standard hat wie das geregelt wird (im MMIO Bereich).
Dann wäre es nämlich möglich die ganze DMA Geschichte nur über den Kernel oder einen Server laufen zu lassen und der Treiber an sich hätte gar kein Zugriff mehr darauf. Damit kannst du dein System dann zu annähernd 100% gegen Treiberfehler absichern (annähernd, weil einem von euch bestimmt ein Grund einfällt warum das nicht so ist ).

Von dieser Idee würde ich lieber Abstand nehmen. Bei PCI gibt es dafür den Class-Code, Du musst bei Deinen Treibern nur sagen ob die anhand der Class-Codes oder anhand der Vendor/Product-ID zugeordnet werden sollen (die zweiten sind die spezielleren und sollten bevorzugt werden).

Und genau das ist ja das Problem. Denn wie könnte man das machen?

Ich hatte mir eine Struktur die ungefähr so aussieht vorgestellt:

Code: [Auswählen]

struct device_t {
 char busName[6]; //in dem Fall "PCI   "
 uint32t classCode;
 uint32t deviceID;
 uint32t vendorID;
}
Damit könnte ich dann eine VendorID und DeviceID von z.B. 0x10000 nehmen. Denn ansich sind die Sachen ja nur 16bit breit und so könnte ich die restlichen 16bit für genau solche Fälle nehmen.

Das Beispiel lässt sich aber noch schön erweitern, so dass nicht mehr so klar ist, dass der eine Treiber der schlechtere generische und der andere der bessere spezielle ist: vesa/nv/nouveau/nvidia. Einmal generisch; einmal ein älterer freier Treiber; einmal ein neuerer, aber noch experimenteller; und zum Abschluss noch ein proprietärer vom Hersteller.

Naja, ich sags mal so, bei mir würde installiert/vorhanden heißen, wenn der Treiber in dem Treiberverzeichnis drin ist. Man sollte sich dann eventuell für später irgendetwas einfallen lassen um einen speziellen Treiber auszuwählen.
Ich habe mir als Ziel aber insbesondere gesetzt, das du das Medium wo mein OS drauf ist, nehmen kannst und in einen anderen PC steckst und da funktioniert es dann auch/trotzdem. Sollte auch funktionieren, da die wichtigen Sachen zum Booten ja eh generische Sachen sind (IDE/SATA/USB/SCSI)!?

Die Entscheidung des Lade-Mechanismus, welchen Treiber er laden soll, muss immer eineindeutig sein. Im Zweifelsfall muss root vorher entscheiden.

Das wird bei meinen Zielen (siehe Oben) wohl sehr schwierig umzusetzen sein. Denn wie willst du den Benutzer fragen, wenn es sich z.B. um den Grafiktreiber handelt.
Was ich mir noch vorstellen könnte ist dass man erst mal generische Treiber nimmt (z.B. VBE) und dann wenn das System soweit ist, das Treiber nachgeladen werden können, sucht man nach spezielleren Treibern und nutzt die dann. Beim Bootvorgang sollte eine Geräteübergabe an einen anderen Treiber eigentlich noch möglich sein.

662

Lowlevel-Coding / Re:Shared Memory

« am: 22. September 2010, 18:54 »

hm, du könntest ja beim Senden schon den virtuellen Speicher im anderen Prozess reservieren (ohne zu mappen, falls das zuviel Probleme macht) und dann dem Sender zurückliefern, dass zumindest das geklappt hat.

Da wären wir wieder bei dem Problem das ich vom Sender aus nicht in die PageTables (bzw. meine anderen Datenstrukturen die dafür verwendet werden) reingucken kann und dann kommt noch hinzu, wenn ich den virtuellen Speicher reservieren kann, dann kann ich ihn auch mappen (es geht ja nur um ein "Stück" was groß genug ist, das der Speicherbereich, der gesendet werden soll, reinpasst).

Aber eigentlich sollte das bei einem Hobby-OS eher kein Problem werden, denke ich.

Ist zwar richtig, sollte aber trotzdem irgendwie behandelt werden.

663

Lowlevel-Coding / Re:Shared Memory

« am: 22. September 2010, 17:34 »

Ich habe mir überlegt eine spezielle Nachricht bzw. einen speziellen Sender zu verwenden um Speicher von einem Prozess zu einem anderen zu senden.

Ich wollte mir jetzt nur mal euren "Segen" holen ob man das so machen kann/sollte oder nicht.

Bei mir kann es als Sender-ID keine "0" geben und diesen Sender wollte ich dann für spezielle Nachrichten verwenden. Sprich als Sender-ID bekommt der Receiver ne "0" und in der Nachricht wäre der erste 32bit-Wert ein Nachrichten-Code und ich würde diese speziellen Nachrichten für irgendwelche System-Nachrichten nutzen.
In diesem speziellen Fall wäre der Code halt das man Speicher von einem anderen Prozess bekommen hat und der zweite 32bit-Wert wäre die Adresse wo dieser Speicher hingemappt wurde.

Soweit so gut. Was mache ich aber, wenn im Adressraum des Receivers nicht genug virtueller Speicher vorhanden ist um den Speicher zu mappen?
Da das ganze ja asynchron wäre, könnte man dem Sender nicht mal sagen, dass der Speicher nicht gemappt werden konnte, das wäre ja noch nicht mal weiter Schlimm.
Aber was passiert mit dem Speicher der gemappt werden sollte, im Adressraum des Senders ist er nicht mehr und in den Adressraum des Receivers passt er nicht rein, also weg damit?
Eine Möglichkeit wäre, die Nachricht (irgendwie) synchron zu machen, sprich der Sender sollte (er muss nicht) auf eine Nachricht des Receivers warten. Ich (als Kernel) würde dann also eine Nachricht an den Sender schicken, wenn der Speicher gemappt werden konnte, das alles Ok ist. Wenn der Speicher nicht gemappt werden konnte, steht halt in der Nachricht der Code für "konnte nicht gemappt werden" drin und die Adresse wo ich (als Kernel) den Speicher wieder zurück gemappt habe.
Gut wäre eine Lösung, was passiert jetzt aber, wenn der virtuelle Speicher des Sender inzwischen auch so voll ist das der Speicher nicht wieder zurück gemappt werden kann?

Wie ihr seht habe ich ein Problem mit der Fehlerbehandlung bzw. ob es richtig ist den Speicher der versendet werden soll im Fehlerfall einfach wieder freizugeben als hätte es ihn nie gegeben.

664

Lowlevel-Coding / Re:Treiber "Management"

« am: 22. September 2010, 17:17 »

Ich empfehle cat /proc/sys/net/ipv4/fuckups, einen Talk (knappe Stunde) vom letzten Chaos Communication Congress. Dort wird beschrieben, wie man durch eine Ansammlung kleiner, vereinzelter, an sich ungefährlicher Bugs in ein Netzwerk eindringen kann.
Warum? Unter anderem werden dort auch zwei Ethernet-Treiber missbraucht, um Payload als neues Paket an den Kernel weiterzureichen.

Ich habe mir das gerade mal angeschaut und von dem was ich verstanden habe (denke ich zumindestens ), kann ich nur sagen, solch Code hat es verdient gecrackt zu werden

665

Lowlevel-Coding / Re:Treiber "Management"

« am: 22. September 2010, 16:30 »

@Svenska

So lange wie man nicht irgendetwas anderes bzw. andersartiges als das DMA "erfindet" was wir momentan haben, kann man sich gegen solche Sachen schwer bis gar nicht schützen, zumal aus 100% Sicherheit nie geben wird.
Programmierfehler wirst du auch in Treibern von vertrauenswürdigen Quellen haben.

Beispiel hierfür wäre "nvidia" gegen "vesa" - ersterer ist, auch wenn älter, sicherlich geeigneter - oder "Chipsatztreiber" gegen "PIO-IDE-Treiber".

Sehr gutes Bsp.! Meine Frage dazu wäre, wie man, wenn man Treiber anhand ihrer unterstützten Geräte irgendwo einsortiert, solche "allgemeinen" Treiber überhaupt behandelt?

Meine spontane Idee wäre, die Geräteart mit einem Hersteller den es nicht geben kann (sprich ein spezieller Code) dafür zu nutzen und sobal ein Treiber für ein Gerät von genau dem Hersteller vorhanden ist, nimmt man diesen anstatt einen für alle Hersteller.
Frage ist nur, gibt es einen solchen Hersteller-Code, der entweder "illegal" ist oder halt einfach nicht verwendet wird?

666

Lowlevel-Coding / Re:Treiber "Management"

« am: 22. September 2010, 12:38 »

Also gut ihr habt mich überzeugt Wenn ein Treiber-Update stattfinden soll, wird für den Anfang ein Neustart notwendig sein.

Was mir noch so im Kopf rumschwirrt. Was macht man wenn man 2 unterschiedliche Treiber/Dateien für das gleiche Gerät hat? Einfach den ersten nehmen oder den neueren?

Das diese Datenbank verwundbar ist wenn das System nicht läuft (und die Platte in einem anderen Rechner einbaut wird) ist mir klar

Sorry, aber an sowas denke ich nicht mal. Wenn es um Sicherheit geht und es möglich ist die Platte auszubauen, an einen anderen PC anzuschließen, die Daten darauf zu manipulieren und die Platte dann wieder zurück zu packen. Wozu dann noch Sicherheit unter deinem OS? Das ein OS zur Laufzeit nicht manipulierbar sein sollte ist klar, aber wenn obiges möglich ist, dann ist das auch egal. Soll heißen wenn es so wichtig ist dass das OS läuft bzw. das die Daten darauf so wichtig sind, dann sollte dieses Szenario überhaupt nicht möglich sein. Ergo wird es einfach ignoriert

Ich mache mir auch keine Illusionen das mein OS irgendwann mal produktiv eingesetzt wird (ich schreibe an einem OS was vorallem und zuerst alte Hardware unterstützt bzw. darauf laufen soll). Ich mache das aus Spaß an der Sache und irgendwo muss man dann auch mal Abstriche machen. Sicherheit ist im Moment sogar ein verdammt großes Problem, da ich davon überhaupt keine Ahnung habe, auch nicht wie man bestimmte Sachen vernünftig macht, aber darüber mach ich mir eigentlich weniger Sorgen.

667

Lowlevel-Coding / Re:Shared Memory

« am: 20. September 2010, 20:33 »

Wie gesagt, meine Lösung war das komplett von der Heapverwaltung zu entkoppeln.

Irgendwo müssen wir uns gegenseitig missverstanden haben, denn das es nichts mit der Heapverwaltung zu tun hat ist klar. Das ist bei mir genauso, aber ich weiß worum es geht, nämlich das man erstmal den Speicher zum sharen braucht.
Dafür würde ich dann sagen, ruft das Programm halt den selben Syscall auf wie malloc auch (um 1 oder mehrere Pages zu allozieren).

Warum sollte das mit shared-memory nicht funktionieren, va. warum nicht in dem von dir beschriebenen Szenario?

Weil ich bei SharedMemory grundsätzlich sage, das es nicht geswappt wird. Denn dann müsste ich im average-case in 2 und im worst-case in noch mehr Prozessen in den PageTables rumspielen und das wird verdammt schwierig, weil auch mein Kernel immer nur die PageTables sieht von dem Prozess der gerade läuft.
Swappen wird sowieso interessant zu implementieren, da ja die Treiber und die VFS Sachen alle im UserSpace laufen (werden).

Ich hab das mit dem verschicken in lightOS implementiert. Das ist so implementiert, dass man mit einer IPC-Message einen shared-memory Bereich mitschicken kann. Möglich war dabei, dass der Speicher aus dem Sender geunmappt wird (also ein kompletter Ownershiptransfer) oder Read-only oder Read-Write zu versenden.

Naja, da ich ja nur fixed-size Nachrichten habe (haben möchte) müsste ich mal sehen, ob ich das als Nachricht oder irgendwie anders machen würde.
Eventuell als ne spezielle Art von Nachricht, nur wie ich das dem Empfänger signalisiere wüsste ich jetzt spontan nicht. Denn was in so einer Nachricht steht ist bei mir nicht festgelegt und von daher habe ich auch nicht sowas wie nen Msg-Code mit dem man die Nachricht bzw. deren Inhalt identifizieren könnte.

668

Lowlevel-Coding / Re:Shared Memory

« am: 20. September 2010, 17:16 »

Worauf du aber achten solltest, wenn du jeden Speicherbereich zu shared-memory machen kannst, ist, dass du nicht einfach mit dem anderen Prozess Dinge sharest, die du eigentlich nicht sharen wolltest, nur weil sie auf der selben Page liegen.

Das ist ein Problem des App-Programmierers und nicht des OS. Denn SharedMemory läuft nunmal nur über Pages.

Ich seh da kein Speicherleck, der Prozess braucht ja nicht den Weg über shared-memory gehen um dein "Leck" zu erzeugen, er kann einfach wie wild Speicher allozieren und nie mehr freigeben.

Wenn ich mal davon ausgehe, das ich irgendwann Swappen kann, dann kannst du mein OS nur ärgern, wenn der Speicher auch nicht ausgelagert wird und das ist nur bei SharedMemory der Fall.

Ich würde lieber den Weg mit der Allow-Liste einschlagen, denn IPC ist schon so schwer genug, da macht es keinen Spaß auch noch auf so ein Timing-Problem Rücksicht zu nehmen

Oder ich müsste mir noch was einfallen lassen, so dass man Pages von einem Prozess zu einem anderem Prozess verschieben/schicken kann. Dieser Speicher würde dann auch beim Sender "ausgetragen" werden.

669

Lowlevel-Coding / Re:Treiber "Management"

« am: 20. September 2010, 17:10 »

Und ja, ich merke schon, dass ich zu sehr Unix denke und du genau deswegen das, was ich sage, ohnehin ablehnst.

Dem muss ich absolut widersprechen, denn ihr habt mich fast soweit, das ich das mit dem automatisch neuladen der Treiber doch lasse.

Das schrieb ich bereits und nahm mir die Freiheit, mich bereits vorauseilend für diese Aussage zu entschuldigen.

Dafür brauchst du dich nicht entschuldigen, aber ich denke mal ein Server-OS hat dann doch noch ein paar mehr Anforderungen als ein "einfaches" Consumer-OS und irgendwo muss man ja mal Abstriche machen

Zweite Sache, und ja ich hacke gern darauf rum, es muss ja nichtmal ein böserartiges Programm sein, welches sich da in dein Treiberverzeichnis schreibt. Wer sagt denn, dass es nicht ein Fehler ist, den du beim Programmieren (Kompilieren) gemacht hast und ihn noch VOR dem Neustart beheben kannst? Oder wer verrät dir, dass beim Kopieren via Netzwerk der Dateistrom nicht abgerissen ist und die Datei unter Umständen nicht vollständig oder (UDP) fehlerhaft ist?

Naja, ich sehe das Problem durchaus ein. Was ich aber auch sehe ist, dass man dieses Problem (fehlerhafter/bösartiger Code) eher schwierig bis gar nicht umgehen kann

Minix als Mikrokernel besteht auch aus solchen Servern (MM, FS, INET). Wenn du allerdings MM beendest, kannst du ihn mangels Speicherverwaltung nicht neustarten. Beendest du FS, kannst du die Treiberdatei nicht mehr laden, da du kein VFS mehr hast. Bei INET gilt entsprechendes, wenn das System für die Treiberdatei Netzwerkzugriff braucht (geschenkt, geht unter Minix nicht). Will heißen: Du kannst nicht jeden Treiber neustarten, zumindest nicht unkonditionell.

Naja, mit diesem Neustarten willst du ja "nur" nen abgestürzten Server neustarten und die Daten sind schon im Speicher vorhanden.
Wenn ich nen Treiber neustarten/updaten würde, dann muss natürlich der neue Treiber auch schon geladen sein. Deswegen sagte ich ja, das man dafür ein vernünftigen Weg braucht, damit das ganze klappt.

670

Lowlevel-Coding / Re:Shared Memory

« am: 20. September 2010, 12:18 »

Ich denke ich werde es so lösen, wie ich es momentan schon habe, sprich wenn kein Prozess mehr den Speicher gemappt hat, dann wird die SharedMemory Struktur gelöscht. Denn würde ich das nicht machen, wäre es ganz einfach mein OS zum stillstand zu bringen, in dem man einfach nen SharedMemory Bereich erstellt, nen anderen Prozess auf die Allow-Liste packt, den Bereich unmappt und dann wieder nen neuen Bereich erstellt und von vorne anfängt, so lange bis kein physischer Speicher mehr vorhanden ist.

Man (als Prozess der den SharedMemory erstellt) muss dann halt nur sicher stellen, das man es irgendwie bei der Kommunikation so macht, das der SharedMemory erst geunmappt wird, wenn der Ziel-Prozess diesen auch gemappt hat.

671

Lowlevel-Coding / Re:Treiber "Management"

« am: 20. September 2010, 12:13 »

Will man das nicht sowieso haben?

Klar, aber eigentlich noch nicht jetzt, das wäre dann doch ein wenig zu viel Aufwand.

Hm, inwiefern ist dein OS in dieser Hinsicht speziell? Und warum hast du dieses Problem nicht, wenn du ELF-Sektionen nimmst? Ich glaube, das musst du etwas ausführlicher beschreiben, damit ich es verstehe.

Naja, jeder Mikrokernel der die Treiber und vorallem die Device-Verwaltung im UserSpace hat, muss sich ja irgendetwas einfallen lassen wie man vernünftig booten kann.

Problem bei mir wäre halt, das ich meinen Device-Server gerne so geschrieben hätte, das er halt nur die Treiber verwendet die auch da sind und wenn später mehr Treiber hinzu kommen (damit meine ich während der Laufzeit) dann guckt er ob er dafür nicht auch Verwendung hat.

Mit diesem Konzept vereinfacht sich das Starten dieses Servers (und von meinem OS allgemein) enorm. Denn wenn ich nur die Treiber im VFS stehen habe die auch als Modul von meinem Bootloader geladen wurden, dann versucht er auch erst gar nicht andere Treiber "nachzuladen", sondern das wird erst dann gemacht, wenn das System so weit ist, dass es Dateien von außen (HDD, USB, CD-ROM, ...) nachladen kann. Deswegen auch die dynamische Erzeugung der Liste zur Laufzeit.

Würde ich das nicht so machen, müsste ich mir was einfallen lassen um den Bootvorgang speziell zu behandeln und das könnte dann ein wenig rumgeeiere werden und das wollte ich eigentlich vermeiden.

Hm, keine Unterstützung für PIC, PIT, PS/2-Tastatur und -Maus, Floppy, ...?

Erwischt

Nein, diese "feste" Hardware wird natürlich unterstützt. Aber du hast da natürlich was sehr interessantes angesprochen. Wie findet man eigentlich raus, ob noch PS/2-Ports vorhanden sind?
Ich meine der PIC und der PIT fallen raus, weil sie in dem Sinne keine Treiber benötigen (die sind fest in meinem Kernel drin), Floppy würde ich dann so machen wie erik es schon vorgeschlagen hat (bekannte Sachen aus dem BIOS als Pseudo-PCI-Geräte in eine Liste packen) und was gibt es sonst noch?

Automatisches Neuladen von Treibern würde ich persönlich auch als extrem riskant (oder schlimmeres) betrachten, so könnte man dem System einfach mal ein fehlerhaftes oder bösartiges Programm unterschieben das dann auch noch mit den Privilegien eines Treibers gestartet wird.

Naja, wie gesagt, damit schiebt sich das Problem, des bösartigen Programms nur bis in den nächsten Bootvorgang.
Außerdem habe ich gerade keine Vorstellung welche besonderen Rechte ein Treiber gegenüber normalen Programmen hat (was natürlich jetzt nur mein OS betrifft, auf anderen OSs kann das wieder anders aussehen).
Das Problem eines fehlerhaften Treibers kannst du sowieso nicht aus der Welt schaffen (es sei denn du machst es wie MS, das nur noch signierte Treiber gestartet werden dürfen).

Ein weiteres Problem beim automatischen Neustart sind Treiber die das Systen permanent braucht, z.B. HDD-Treiber oder Dateisystem-Treiber.

Also bei sowas LowLevel wie dem HDD-Treiber seh ich da eher weniger Probleme. Wenn man sich ein vernünftiges Protokoll einfallen lässt sollte das relativ schmerzlos und schnell über die Bühne gehen. Aber auch ein VFS-Modul sollte man entladen können und das fällt bei mir auch nicht in die Kategorie Treiber, sondern wird als ne Art Add-On für den Storage-Server verwendet (ich bin da ziemlich BeOS/Haiku belastet ).
Zumal man jeden Treiber "runterfahren" können sollte und dann wird er einfach neu gestartet. Ob und wie das jetzt genau funktioniert kann ich mir immer noch Gedanken machen, wenn es dann soweit ist.

Ich hätte es nur schon gerne, das man mein OS nicht neustarten muss, nur um einen neuen Treiber zu laden bzw. einen zu updaten.

Was natürlich ausfällt ist Busmanager neu zu laden, zumal diese wiederum bei mir unter die Kategorie Add-On des Device-Servers fallen (also PCI, ISA, USB, ...).

672

Lowlevel-Coding / Re:Treiber "Management"

« am: 20. September 2010, 10:25 »

Du bräuchtest einen Syscall, der dem Devicemanager mitteilt, dass ein Treiber neu geladen/gestartet werden soll.

Das ist nicht böse gemeint, aber damit hast du mal wieder (für mich) bestätigt das du nur im Unix-mäßig denkst.
Ich habe einen Device-Server, dem müsste man irgendwie ne Nachricht schicken.

Alternativ, da du ja ohnehin Funktionen zum Laden und Entladen von Treibern brauchst, kannst du diese beiden Funktionen auch exportieren und dafür benutzen. Der Fall von "rmmod blubber; modprobe blubber". Diese Sequenz kannst du dann ja auch von deinen Bau-/Installationsscripten aufrufen lassen.

Ist mir wieder viel zu Unix-mäßig. Ich will Skripte soweit es geht vermeiden und schon gar nicht soll sich ein User mit einem Skript beschäftigen müssen (wenn er das will, ist das ne ganz andere Geschichte).

Deine Variante ist für Treiberentwickler vorteilhaft, aber für den Produktionseinsatz wäre es mir zu ... gefährlich. Gut, dein OS wird eher kein Produktionseinsatzsystem sein, aber ich denke halt immer an sowas.

Ich vermute mal mit Produktionseinsatz meinst du sowas wie Server und mehr geschäftlich genutzt?! Ich habe mir als "Ziel" (es sei mal dahin gestellt ob ich es jemals erreiche) gesetzt ein Consumer-OS zu schreiben, wenn man das ganze auch als Server-OS nutzen könnte ist das auch Ok, aber es ist kein Ziel.

Einen echten Grund dazu sehe ich nicht. Aber wenn man das unbedingt machen will, dann ist die ELF-Sektion wohl das vernünftigste.

Der Grund (für mich) ist die Einfachheit. Eine andere Möglichkeit wäre ein Package-System zu nutzen oder zu entwickeln, mit dem man nicht nur Programme, sondern auch Treiber installieren/deinstallieren kann.
Obwohl ich da dann wieder vor dem Problem stehe, wie ich mein OS vernünftig booten kann ohne alzu viele Ausnahmeregelungen dafür zu schaffen.

Ich werd dann also die ELF-Sektion Variante nutzen.

Noch was zum ISA-Bus, ich habe mir überlegt nur ISA-Hardware zu unterstützen die Plug&Play fähig ist, damit dürfte dann doch eigentlich das Proben entfallen oder?

673

Lowlevel-Coding / Re:Treiber "Management"

« am: 19. September 2010, 22:27 »

@taljeth

Was passiert, wenn ein Treiber in der Datenbank steht, aber physisch, sprich als Datei, nicht mehr vorhanden ist?

Ich würde halt die ganze Geschichte (Liste der unterstützen Geräte) gerne in der eigentlichen Treiberdatei drin haben.
Einen neuen Prozess erstellen nur am an diese Liste zu kommen ist mir zu langsam und die Liste irgendwo in der Datei zu haben (durch irgendeine Magic-Konstante markiert) ist mir auch zu aufwendig und langsam. Daher die Idee mit der extra ELF-Sektion.

Ich bin aber gerne offen für Vorschläge oder Gegenargumente.

Besonders die Sache mit dem automatischen(!) Treiberneustart finde ich sehr unschön, den (Re-)Ladevorgang selbst würde ich immer manuell anstoßen lassen müssen.

Was würdest du vorschlagen, wie man das sonst macht, weil ich da ja dann irgendeine Art Interface für haben müsste und da müsste dann auch sichergestellt werden, dass das nicht jeder machen kann.
Meine Variante ist natürlich besonders für Treiberentwickler sehr vorteilhaft.

674

Lowlevel-Coding / Re:Treiber "Management"

« am: 19. September 2010, 21:07 »

Naja, du schaust beim Systemstart nach, ob die Liste existiert. Wenn nein, erzeugst du sie. Wenn ja, schaust du nach, ob eine Treiberdatei neuer ist als deine Liste (damit sparst du dir, die Dateien zu öffnen).  Ist deine Liste veraltet, erzeugst du eine neue.

Da sind wir dann bei dem Problem mit dem Booten meines Systems, das ist leider nicht so einfach. Außerdem möchte ich einfach auch bei jedem Systemstart die Liste dynamisch erzeugen.
Der Grund dafür ist, ich lade nur die wichtigsten Treiber mit meinem Loader und nur diese tauchen am Anfang im Treiberverzeichnis auf und können genutzt werden. Würden da schon alle Treiber drin stehen, hätte ich das Problem das ich sie nicht laden kann, da der Treiber zum Laden wahrscheinlich noch gar nicht gestartet wurde.
Mit meiner dynamisch erzeugten Liste umgehe ich dieses Dilemma.

inde ich unelegant, weil du damit quasi einen Daemon im Hintergrund laufen hast, der ständig ein (unwahrscheinliches) Ereignis abprüft.

Das ist so nicht richtig. Ich will in meinen Storage-Server sowas wie nen Node-Monitor einbauen, sprich du registrierst dich als Empfänger, dass du ne Nachricht bekommen willst wenn sich ein einer bestimmten Node was ändert. Da läuft dann kein Daemon im Hintergrund, sondern das macht alles der Storage-Server.

Betone, dass der alte Treiber (im RAM) manuell ein Signal zum "runterfahren" kriegt und wir sind uns einig.

Genau, das (den Treiber runterfahren und den neuen starten) macht natürlich der Device-Server.

Betrifft den automatischen Restart von aktualisierten Treibern: Wenn dein Devicemanager neue Treiberversionen direkt automatisch startet, kannst du damit dein System zerschießen.

Das Problem würde sich dann (wenn ich das nicht machen würde) ja nur auf den nächsten Systemstart verschieben. Außerdem müsste man das dann irgendwie elegant lösen, ich meine ich möchte nicht, das ein Treiber einfach so von jedem Prozess überschrieben werden kann. Da müsste dann jedes mal was "aufleuchten", so wie das UAC

Du hast nur noch nichts zu der Idee gesagt, das ich eine spezielle Sektion in der ELF-Datei haben möchte wo drinsteht welche Geräte der Treiber unterstützt. Ich finde das so halt besser/performanter als wenn ich den Treiber erstmal starte (muss nen neuer Prozess für erzeugt werden) und ihn dann sozusagen berichten lasse.

675

Lowlevel-Coding / Re:Treiber "Management"

« am: 19. September 2010, 18:33 »

Du könntest eine sortierte statische Liste machen, in der alle unterstützten Hersteller-/Gerätenummern aufgeführt sind und darin suchen, wenn du ein Gerät findest. So eine Art Datenbank.

Das ist nicht ganz das was ich erreichen will. Die Frage ist dann wann wird diese Datenbank erstellt und wo bekommt sie wie ihre Daten her?

Statisch, weil du diese nur aktualisieren musst, wenn ein Treiber aktualisiert wurde und nun neue/zusätzliche IDs unterstützt oder ein neuer Treiber da ist.

Da triffst du schon eher das was ich erreichen will. Diese Datenbank sollte jedes Mal aktualisiert werden, wenn eine Veränderung im Treiberverzeichnis (löschen/neu/geändert) stattgefunden hat.

Das dürfte wesentlich schneller sein, als jeden Treiber erstmal zu öffnen und dann festzustellen, dass er total sinnlos auf diesem System ist.

Wo wir wieder bei der Frage wäre, wo bekommt die Datenbank die Daten her? Ich muss die Datei öffnen um zu wissen welche Geräte der Treiber unterstützt.
Steht die Datei schon in der Datenbank, würde ich aufs letzte Änderungsdatum gucken und schauen ob der Treiber eventuell neuer ist als der der in der Datenbank eingetragen wurde.

Treiber neu laden würde ich jedenfalls nie automatisch machen; sonst kann jemand einen Server zum Absturz bringen, indem er Schreibzugriff auf das Treiberverzeichnis erlangt.

Aber genau das möchte ich (nicht den Absturz ). Ein Treiberupdate wäre dann einfach, neuen Treiber über alten Treiber kopieren und dem alten Treiber signalisieren das er "runtergefahren" wird und neuen Treiber laden.
Genauso einfach sind dann Installation/Deinstallation, einfach in das Verzeichnis kopieren bzw. einfach daraus löschen/verschieben.

Wie genau stellst du dir das vor, dass ein Server abstürzt, weil jemand Schreibzugriff auf das Treiberverzeichnis bekommen hat?

Für PCI/USB kannst du ja vom Devicemapper (der die Bussysteme verwaltet) die Treiber laden lassen, ISA wäre manuell relativ sinnvoll (eine feste Liste zu ladender Treiber), da man ISA-Geräte nur proben kann.

Wollte ich genauso machen, sprich der Busmanager (außer ISA) hat ne Liste mit Geräten die im System vorhanden sind und dann wird in der Datenbank nachgeguckt ob ein Treiber vorhanden ist (falls ja -> wird dieser geladen) und wenn der Treiber geladen ist, muss dieses Gerät in eine Liste "Geräte mit laufenden Treiber" gepackt werden.

Ziel ist es vorallem meinen Bootvorgang (für mich) zu vereinfachen und die Installation/Deinstallation/Update zu vereinfachen.

676

Lowlevel-Coding / Treiber "Management"

« am: 19. September 2010, 18:05 »

Ich mache mir gerade Gedanken darüber wie man Treiber performant "managen" kann.

Damit meine ich, das z.B. nicht jeder Treiber geladen und ausgeführt wird und dann guckt ob ein Gerät, das er unterstützt, vorhanden ist, sondern das ein Treiber auch immer nur dann ausgeführt wird, wenn ein Gerät für ihn vorhanden ist.

Ich hatte mir da folgendes überlegt. Ich könnte als Anforderung für einen Treiber sagen, dass dieser eine bestimmte ELF-Sektion haben muss, wo in einer genau definierten Datenstruktur die Geräte drin stehen, die er unterstützt.
Problem wäre hier, das ich das ganze dann für jedes Bussystem (ISA, PCI, USB, ...) extra machen müsste.
Vorgestellt habe ich mir das so, dass der Device-Server das Verzeichnis wo die ganzen Treiber drin sind "beobachtet" (also benachrichtigt wird, wenn eine Änderung aufgetreten ist) und dann alle Dateien in dem Verzeichnis "parst" (also den ELF-Header laden und die spezielle Sektion, wo die Daten drin sind) und sich eine Liste anlegt.

Soweit so gut. Wie könnte man es machen, das die Liste nicht bei jeder Änderung neu erstellt wird? Ich dachte, das man vielleicht neben dem Dateinamen, noch die Zeit der letzten Änderung speichert. Damit kann ein Treiber gegebenenfalls neugeladen werden, wenn eine neuere Version in das Verzeichnis kopiert wurde.

Was haltet ihr davon, was würdet ihr anders/besser machen?

677

Lowlevel-Coding / Shared Memory

« am: 19. September 2010, 17:48 »

Ich bin gerade über einen Bug in meinem Shared Memory Code gestolpert und bin mir bei einer Sache nicht ganz sicher wie man es am besten macht.

Mein Shared Memory funktioniert so, das ein Prozess einen Bereich als SharedMemory erstellen kann (sprich der Speicher dafür muss schon im Prozess vorhanden sein). Will er (der Prozess) anderen Prozessen den Zugriff auf den Speicher geben, muss er einen "SharedAllow"-Syscall aufrufen, dem er die Adresse des Shared Memory und des Ziel-Prozesses übergibt.
Der Zielprozess ruft dann einen "SharedMap"-Syscall auf mit der ID des SharedMemory, hat er seine Arbeit erledigt ruft er den "SharedUnmap"-Syscall auf.

Mit dem letztgenannten Syscall (SharedUnmap) hab ich dann so meine Probleme. Im Moment habe ich nen Counter wie oft ein Shared Memory Bereich irgendwo gemappt ist und nur wenn dieser Counter "0" wird, wird die ganze Strukur (die die Daten zur Beschreibung des Shared Memory beinhaltet) wieder freigegeben/gelöscht.
Nur kann es jetzt die Situation geben, das ein anderer Prozess noch gar nicht an der Reihe war (zwecks Scheduling-Strategie) und den Speicher noch nicht mappen konnte. Dadurch würde diese Shared Memory nicht mehr existieren und der Empfänger würde nen Fehler zurückbekommen.
Das ist natürlich unschön. Wenn ich sage das ein Shared Memory solange exisitiert bis alle Prozesse, die in der "Allow"-Liste stehen, diesen auch einmal gemappt und dann wieder geunmappt haben, mache ich mir sorgen um die Sicherheit bzw. würde ich das dann fast schon als Speicherleck sehen.

Was meint ihr wie man das lösen sollte?

678

Lowlevel-Coding / Re:Treiber bei einem Mikrokernel

« am: 12. September 2010, 15:09 »

Um nochmal was zu dem Thema BIOS und PCI Ressourcen zu sagen, ich habe gerade mal auf meinem Sockel 940 (Opteron) Board im BIOS nachgeguckt und da steht als Erklärung für die genannte Option (Plug&Play OS available) das nur die Ressourcen initialisiert werden, die zum Booten nötig sind.
Damit kann man mit 100%er Sicherheit davon ausgehen, das auch Windows sowas beherrscht!

679

Lowlevel-Coding / Re:Treiber bei einem Mikrokernel

« am: 09. September 2010, 14:23 »

Es macht auf jeden Fall keinen Sinn wenn das BIOS nur einen Teil der PCI-Geräte konfiguriert und den Rest dem OS überlasst eben weil sich damit die Adressen der vom BIOS konfigurierten Geräte ändern können und damit das BIOS nicht mehr funktionieren würde (also z.B. keinen INT 13h mehr anbieten kann).

Dem wiederspreche ich mal. Solange du den Kompatibilitätsmodus des IDE-Kontrollers nicht ausstellst, ist der immer hinter den gleichen Ports erreichbar.
Außerdem hat Svenska doch gesagt, das nur das was zum Booten gebraucht wird initialisiert wird und dass das BIOS nach dem Booten eines OS noch funktioniert, davon gehe ich sowieso nicht aus. Wer weiß was das OS alles geändert hat, aber das ist ja auch sein gutes Recht

Edit::

Habe das falsche "nicht" entfernt.

680

Lowlevel-Coding / Re:Treiber bei einem Mikrokernel

« am: 08. September 2010, 17:10 »

Arrr ....  (ganz ruhig Erik, nicht aufregen)

Der Punkt ist, ich habe trotzdem Recht  (Die Ressourcen können geändert werden und das ist auch vorgesehen)

Ich möchte sogar behaupten das Linux und Windows Code haben für eine neue Ressourcenzuweisung und das es halt den Fall gibt das die Ressourcen gar nicht oder fehlerhaft zugewiesen wurden.