Autor Thema: Allgemeine Fragen  (Gelesen 26925 mal)

Programm Noob

  • Gast
Gespeichert
« am: 02. September 2010, 22:47 »
Wie ihr es vielleicht schon in Wiki gelesen habt, hab ich die Schauze voll von diesen nicht funktionierdem kaputten zusammenkopiertem Code-Berg.
Deshalb rewrite ich NandOS und will einiges besser und ein paar Sachen voher besser planen. Deshalb habe ich ein paar Fragen dazu.

Frage 1: Auf was muss ich achten, das ich später ohne Probleme 64 Bit unterstützen kann?

Frage 2: Kann mir mal einer VM 86 Erlären?

Frage 3: Soll ich erst Speicherverwaltung P und V planen und implementieren oder erst multitasking?

Frage 4: Welche IPC Methode würdet ihr mir empfehlen?

Frage 5: Wann sollte ich VFS implementieren?

Programm Noob

PS: Bitte schreibt hier keine Scheiße.
« Letzte Änderung: 02. September 2010, 22:49 von Programm Noob »

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 03. September 2010, 08:56 »
Frage 1: Auf was muss ich achten, das ich später ohne Probleme 64 Bit unterstützen kann?
Vergiss das mit "ohne Probleme", das klappt ja schon bei der Architektur nicht, für die man im Moment schreibt. ;)

Ansonsten eben die grundsätzlichen Regeln der Plattformunabhängigkeit. Plattformabhängige Teile in eigene Dateien auslagern, kein Assembler in plattformunabhängigen Teilen, die richtigen Datentypen verwenden (z.B. uintptr_t statt int, wenn ein Pointer reinsoll).

Zitat
Frage 2: Kann mir mal einer VM 86 Erlären?
Ja, das Intel-Manual. Das Wiki und der tyndur-Source enthalten evtl. noch ein bisschen Informationen, um das zu veranschaulichen.

Zitat
Frage 3: Soll ich erst Speicherverwaltung P und V planen und implementieren oder erst multitasking?
Um es mit meinem alten Mathelehrer zu sagen: Der eine mag lieber Vanilleeis, der andere lieber Schokoladeneis.

Zitat
Frage 4: Welche IPC Methode würdet ihr mir empfehlen?
Lies dir einen von den langen Threads mit erik durch, da geht es immer nur um genau diese Frage. Wie die Länge dieser Threads schon vermuten lässt, gibt es keine kurze Antwort auf die Frage.

Zitat
Frage 5: Wann sollte ich VFS implementieren?
Sobald du irgendwas mit Dateien machen willst.

Zitat
PS: Bitte schreibt hier keine Scheiße.
Scheiße.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Programm Noob

  • Gast
Gespeichert
« Antwort #2 am: 03. September 2010, 09:38 »
Das Problem mit VM86 ist, das ich aus den Intel Manuals und dem Tyndursourcecode nicht Schlau werde. Ich fände es echt nett, wenn mir das mal einer erklären könnte.

Programm Noob

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 03. September 2010, 09:54 »
Was genau an VM86 ist denn nicht verständlich? Wenn du konkrete Fragen stellst, kann man vielleicht sogar helfen. Aber ein komplettes Tutorial mit Code zum Kopieren wird dir wahrscheinlich niemand mal eben schreiben.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Programm Noob

  • Gast
Gespeichert
« Antwort #4 am: 03. September 2010, 13:49 »
Wenn ich das VM Bit in den eflags aktiviere und den stack, so wie ere im Wiki beschrieben ist aufbaue, geht es nicht. es kommen nur fehler, welche weiß ich gerade nicht, dauert auch noch ein wenig, da ich gerade bei der gdt bin. Ein Tutorial wäre zwar schön, aber Code zum kopieren ist zwar schön zum ansehen, aber ich kopiere nicht mehr.

XanClic

  • Beiträge: 261
    • Profil anzeigen
    • github
Gespeichert
« Antwort #5 am: 03. September 2010, 15:30 »
Wenn ich das VM Bit in den eflags aktiviere
Ich hoffe nicht, dass das
pushfd
pop eax
or eax,0x20000
push eax
popfd
heißen soll, das wäre nämlich falsch (wie taljeth in #lost mal sagte, würde da wohl gar nichts passieren).

Man beachte, was im Wiki zum Stack steht: „Aufbau eines Stacks direkt vor dem iret zu einem VM86-Task:“ – will sagen, der einfachste Weg ist es, die ganzen für iret nötigen Sachen auf den Stack zu legen (was, steht ja im Artikel), dabei im entsprechenden eflags-Feld halt Bit 17 gesetzt haben und dann ein iret auszuführen.

Vielleicht sollte ich mal ins Wiki schreiben, dass „setzen“ nicht per „popfd laden“ heißt…

Auf was muss ich achten, das ich später ohne Probleme 64 Bit unterstützen kann?
1. dass du lieber „worauf“ benutzt und 2. dass du dir bewusst bist, dass vm86 nur bei i386 geht.


EDIT: Hab das jetzt ins Wiki geschrieben. Hoffentlich ist es jetzt klarer (wobei auch vorher niemand verboten hat, mal ins Manual zu schauen, wie es funktioniert).
« Letzte Änderung: 03. September 2010, 15:36 von XanClic »

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 03. September 2010, 15:36 »
Hallo,


hab ich die Schauze voll von diesen nicht funktionierdem kaputten zusammenkopiertem Code-Berg.
Weshalb hast Du dann damit erst angefangen? ;)
Bei zusammen kopiertem Code kommt nur extrem selten was gescheites bei raus, falls Du dieses Forum aufmerksam verfolgst werden Dir etliche Beispiele dafür auffallen.

Deshalb rewrite ich NandOS und will einiges besser und ein paar Sachen voher besser planen.
Das kannst Du schon mal gleich vergessen. Bis man es schafft ein Projekt geradlinig von der Planung, über die Projektierung, durch die Implementierung zum Ziel zu bringen braucht man schon ein gehöriges Maß an Erfahrung (selbst langjährige Profis bekommen das nicht immer hin). Und das gilt in besonderem Maße für ein OS-Projekt! Du wirst mit hoher Wahrscheinlichkeit noch mehrere Versuche brauchen bis Du was "vorzeigbares" (also etwas für das man sich wenigstens nicht zu schämen braucht) zu Stande bringst. Lass Dich davon nicht entmutigen, aber es wäre falsch wenn wir Dir einen leichten Weg versprechen den es einfach nicht gibt.

Frage 1: Auf was muss ich achten, das ich später ohne Probleme 64 Bit unterstützen kann?
Schreibe "portablen" Code. Was das genau bedeutet wirst Du auch erst mit der Zeit lernen. Ich musste vieles davon auch erst auf die harte Tour lernen indem ich mit nicht-portablen Code gegen die Wand gebrettert bin. Du wirst Dir dabei mit Sicherheit den einen oder anderen blauen Fleck holen, viel Spaß damit.

Frage 2: Kann mir mal einer VM 86 Erlären?
Den brauchst Du noch nicht.

Frage 3: Soll ich erst Speicherverwaltung P und V planen und implementieren oder erst multitasking?
Eine bessere Antwort als die welche Dir taljeth gegeben hat gibt es einfach nicht!

Frage 4: Welche IPC Methode würdet ihr mir empfehlen?
Eine die Deinen Ansprüchen genügt und vom Schwierigkeitsgrad her Deinen Fähigkeiten entspricht! Wenn das nicht zusammenpasst musst Du an einem von beiden was ändern.
Der Relevante Punkt beim IPC ist wie die Aufträge dem Service zugestellt werden, da gibt es im wesentlichen 3 Möglichkeiten:
  • aktives Abholen, dazu blockiert aber Dein Service oder Du hast mehrere Threads, die meisten OSe dürften das benutzen
  • zustellen lassen wie UNIX-Signale, einfach zu implementieren aber leider mit einigen Nachteilen verbunden (für die klassischen Signale ist das Okay aber für intensiv genutztes IPC eher ungeeignet)
  • zustellen lassen mit PopUp-Threads, hat meines Wissens nach noch nie jemand implementiert
Such Dir eine Variante aus (denke dabei an die 2 obigen Kriterien) und wenn Du konkrete Fragen hast kannst Du die gerne stellen.

Frage 5: Wann sollte ich VFS implementieren?
Unmittelbar bevor Du es benötigst. Bei einem Micro-Kernel-OS (ich vermute das Du eines schreiben möchtest sonst hättest Du nicht nach IPC gefragt) ist der VFS ein ganz normaler User-Mode-Prozess und kommt erst an die Reihe nachdem der Kernel schon mal einigermaßen gut läuft.

PS: Bitte schreibt hier keine Scheiße.
Na hör mal, was ist denn das für ein Ton? Schonmal vorsorglich rumpöbeln geht IMHO gar nicht, das kannst Du immer noch machen wenn Du wirklich unverschämte Antworten kriegen solltest. Außerdem hängt die Qualität der Antworten wohl auch erheblich von der Qualität Deiner Fragen ab!


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

Programm Noob

  • Gast
Gespeichert
« Antwort #7 am: 05. September 2010, 22:40 »
Ich stellte mir gerade die Frage, ob ich mein eigenes Treiberinterfache weiterentwickeln soll, oder CDI implementieren soll.

Damit ich mich besser entscheiden kann, ein paar fragen bezüglich CDI.

Frage 1: Gibt es Probleme mit CDI unter 64 bit bzw. Hat schonmal einer CDI erfolgreich in einem 64 Bit OS eingesetzt?

Frage 2: Was für Treiber sind momentan in arbeit bzw. wie viele Treiber kommen so pro Monat dazu?

Ich hoffe ihr könnt mir diese beiden Fragen beantworten.

Programm Noob

XanClic

  • Beiträge: 261
    • Profil anzeigen
    • github
Gespeichert
« Antwort #8 am: 05. September 2010, 23:33 »
Frage 1: Gibt es Probleme mit CDI unter 64 bit bzw. Hat schonmal einer CDI erfolgreich in einem 64 Bit OS eingesetzt?
Pedigree unterstützt CDI und es gibt davon wohl auch eine 64-Bit-Version, ob beides zusammen existiert, weiß ich nicht – da ich aber nie Beschwerden von pcmattman über CDI und amd64 gehört habe (und solch eine Unterstützung ist schon angedacht, wenn es z. B. ein Flag für cdi_mem_alloc gibt (CDI_MEM_DMA_4G), das dafür sorgt, dass Speicher unterhalb von 4 GB zurückgegeben wird, dann ist das schon ein deutliches Zeichen dafür), wird das schon der Fall sein.

Was für Treiber sind momentan in arbeit bzw. wie viele Treiber kommen so pro Monat dazu?
Wirklich in direkter Arbeit wären wohl aktuell das CDI.video-Interface und der erste Treiber dafür, VBE. Allgemein in Arbeit (kann aber noch eine Weile dauern, und das ist wohl nicht zuletzt auch meine Schuld) wären CDI.audio (und hier ein AC97-Treiber) sowie CDI.usb (das kann allerdings wirklich noch lange dauern, wenn es überhaupt realisiert wird).
Ansonsten arbeite ich noch theoretisch an einem tulip-Treiber (eine Netzwerkkarte), aber andere neue Treiber fallen mir im Moment nicht ein – wobei mir auch kein Treiber einfällt, den ich sonst gern hätte. Mit tulip wäre noch die andere Netzwerkkarte abgedeckt, die ich habe (neben rtl8139), und mit AC97 könnte ich zumindest einen Computer versorgen (HD Audio ist wohl etwas schwieriger, ich weiß gar nicht, ob es da überhaupt offizielle Spezifikationen gibt).

Tjo, wie viele pro Monat dazukommen… Ich muss ehrlich sagen, dass ich, seitdem ich CDI mitverfolge, keinen neuen Treiber gesehen habe. Will sagen, derzeit tendiert die Zahl gegen 0 (wobei ich, wie gesagt, auch keinen Treiber wirklich vermisse, an dem nicht bereits so halb gearbeitet würde).

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 05. September 2010, 23:41 »
Nicht, dass die Zahl irgendeine Bedeutung hätte, aber... Der erste Commit im CDI-Repo ist von Dezember 2007, also 33 Monate. Ich zähle im Moment 11 Treiber. Macht pro Monat einen Dritteltreiber.

Zu den Treibern, die halbwegs aktiv in Arbeit sind, würde wohl FAT auch noch zählen.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Programm Noob

  • Gast
Gespeichert
« Antwort #10 am: 05. September 2010, 23:46 »
Ok dann scheint es wohl unter x86-64 zu gehen, aber das nur so wenige Treiber entwickelt werden...
Ich glaube ich schreibe einfach einen Wrapper, um CDI Treiber, in dem von mir bisher nur auf dem Papier entwickeltem Treiberinterface zu nutzen.

Programm Noob

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 06. September 2010, 00:09 »
Wenn du auch einen Treiber schreibst, sind es schonmal mehr. ;)

Ich glaube aber auch, dass du erstens unterschätzt, wie viel Arbeit ein Treiber machen kann, und zweitens überschätzt, wie viele Treiber man in der Praxis tatsächlich braucht.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Programm Noob

  • Gast
Gespeichert
« Antwort #12 am: 06. September 2010, 06:52 »
Ich weiß ein Treiber zu schreiben ist ne menge arbeit, ich schreibe momentan parallel zu entwicklung der beiden neuen Kernel an Floppy Treiber für NandOS.

Naja man benötigt nicht umbedingt viele Treiber auf einmal. Aber rum auf portabel zu seon benötigt man viele Treiber. Wir benötigen bei uns im Haus 5 verschiedene Netzwerkkartentreiber und 3 Verschiedene Soundtreiber. Dazu kommen dann noch die Treiber für Maus, Tastatur, RS232, Parallele Schnittstelle, ATA, SATA,  Floppy, USB,Fireware, Grafik, Drucker, Webcam usw.Also Treiber braucht man schon recht viele.

Wenn ich CDI implementiere, dann werde ich den einen oder anderen Treiber für CDI schreiben, sollte ich jedoch nur einen Wrapper schreiben, werde ich gucken wie es mit einem Wrapper in die andere Richtung aussieht. :-)

Programm Noob

Tederian

  • Beiträge: 6
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 06. September 2010, 08:56 »
Die Frage ist welche Treiber du überhaupt brauchst.
Webcam bringt dir herzlichst wenig ohne VGA, Drucker auch nur wenig.
Grafik haben meist keine offenen Dokumentationen, und auch wenn sie es haben sind diese alles andere als gut verständlich.
Besser an der OS-Architektur herumtüfteln als die Zeit mit Treiber zu verschwenden :P

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 06. September 2010, 09:26 »
Ich weiß ein Treiber zu schreiben ist ne menge arbeit, ich schreibe momentan parallel zu entwicklung der beiden neuen Kernel an Floppy Treiber für NandOS.
Floppy ist relativ harmlos. Okay, die Hardware kann störrisch sein, aber sie ist halbwegs vernünftig dokumentiert und fast jeder hat einen Floppytreiber, so dass man auch Code vergleichen kann, wenn was nicht tut.

Spaßiger wird das ganze schon, wenn man Treiber für eine Hardware schreibt, wenn man nur Dokumentation zu "ähnlicher" Hardware hat. Und selbst mit vernünftiger Dokumentation schwer sind Dateisystemtreiber, die nicht ab und zu das Dateisystem kaputtmachen. ;)

Zitat
Wenn ich CDI implementiere, dann werde ich den einen oder anderen Treiber für CDI schreiben, sollte ich jedoch nur einen Wrapper schreiben, werde ich gucken wie es mit einem Wrapper in die andere Richtung aussieht. :-)
Wenn du dir den Wrapper sparst, kannst du die Zeit besser darin investieren, CDI zu verbessern. :)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Programm Noob

  • Gast
Gespeichert
« Antwort #15 am: 06. September 2010, 09:57 »
Klar Webcam bringt noch nichts, aber es sollte nur ne auflistung von Treibern sein, die irgendwann mal benötigt werden.
Für Grafik gibts VESA. Um CDI zu verbessern müsste ich mich bis ins tiefste innere von CDI reinarbeiten. Ich werde mir es nochmal überlegen.

Programm Noob

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 06. September 2010, 11:10 »
CDI ist eine Schnittstelle. Da gibt es nicht viel inneres. ;)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #17 am: 06. September 2010, 11:16 »
(HD Audio ist wohl etwas schwieriger, ich weiß gar nicht, ob es da überhaupt offizielle Spezifikationen gibt).
Gibt es, siehe intel.com
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #18 am: 06. September 2010, 12:23 »
Hallo,


Zum CDI hätte ich auch noch ein paar Fragen (wo wir gerade dabei sind) :

Wie finden eigentlich die Treiber usw. zu einander?
Ich stelle mir das so vor das der PCI-Treiber eine Reihe an Geräten findet (enumeriert), diesen passende Ressourcen zuweist (was beim PC ja schon durchs BIOS erledigt wurde) und dann anhand von Vendor/Device-ID einen spezifischen Treiber oder anhand vom Class-Code einen generischen Treiber lädt (hier ist die Reihenfolge wichtig). Dieser Treiber müsste vom PCI-Treiber für das gefundene Gerät gestartet werden (was auch mehrmals passieren kann) und sich dann ans CDI "anmelden" können (eben auch mehrmals, falls mehrere gleiche Geräte vorhanden sind). In diesem Zusammenhang sind mir die Funktionen cdi_run_drivers() und cdi_driver_register() noch ziemlich unklar.

Wo werden eigentlich die gefundenen Blockdevices den einzelnen Dateisystemen zugeordnet oder in Partitionen gesplittet?
Gerade für die Dateisysteme vermisse ich eine Funktion die einem Dateisystemtreiber die ersten paar Sektoren einer Partition oder eines Blockdevices (falls nicht partitioniert) übergibt damit das Dateisystem erst einmal prüfen kann ob es sich überhaupt dafür zuständig fühlt und dann vom CDI eine neue Instanz gestartet wird.

Wie kann sich der IP-Stack an CDI anmelden?
Zumindest bei einem Micro-Kernel-OS ist er ja nicht direkt Bestandteil des eigentlichen OS selber. Obwohl man auch sagen könnte das bei einem richtigen Micro-Kernel-OS der Kernel noch nicht mal weiß das CDI überhaupt existiert.

Bei den PCI-Geräten ist immer nur ein IRQ erlaubt, warum?
Könnte man die IRQs nicht auch als Ressource betrachten, so wie Speicherbereiche und I/O-Port-Bereiche?
Mir ist klar das in aktuellen PCs kaum ein Gerät mehr als einen IRQ benutzt aber viele (wie AHCI) sind zu mehr fähig.


Ein bisschen mehr Beschreibung des "Drumherum" wäre nicht schlecht.
Wenn CDI nur eine Sammlung von Funktionsprototypen ist dann ist sein Nutzwert IMHO noch recht gering, es sollte auch ein Konzept existieren wie man CDI benutzen muss damit es einem auch wirklich was hilft.


Gibt es, siehe intel.com
Hast Du auch die Seite gelesen? Da gibt es einen Abschnitt der mit "Implementation of the High Definition Audio Specification requires a license from Intel. ..." anfängt. Die Frage ist: bezieht sich das nur auf HW-Implementierungen oder sind da auch SW-Implementierungen, Treiber aber auch Emulatoren, mit inbegriffen? Ich glaube zwar nicht das Intel irgendwelchen Hobby-OS-Devern eine Horde Anwälte aufhetzen würde, nur weil die einen (rudimentären) Treiber für das HD-Audio programmieren, aber mal nachfragen sollte man eventuell schon. Bei den anderen Spezifikationen aus dem Hause Intel ist das etwas klarer formuliert.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #19 am: 06. September 2010, 12:43 »
Wie finden eigentlich die Treiber usw. zu einander?
Ich stelle mir das so vor das der PCI-Treiber eine Reihe an Geräten findet (enumeriert), diesen passende Ressourcen zuweist (was beim PC ja schon durchs BIOS erledigt wurde) und dann anhand von Vendor/Device-ID einen spezifischen Treiber oder anhand vom Class-Code einen generischen Treiber lädt (hier ist die Reihenfolge wichtig). Dieser Treiber müsste vom PCI-Treiber für das gefundene Gerät gestartet werden (was auch mehrmals passieren kann) und sich dann ans CDI "anmelden" können (eben auch mehrmals, falls mehrere gleiche Geräte vorhanden sind). In diesem Zusammenhang sind mir die Funktionen cdi_run_drivers() und cdi_driver_register() noch ziemlich unklar.
In der cdi_driver-Struktur des Treibers wird ein Bus angegeben, hier halt PCI. Sobald der Treiber dann initialisiert wurde, ruft die CDI-Implementierung die init_device-Methode des Treibers auf, für jedes der PCI-Geräte (die noch keinen Treiber haben). Und falls dem Treiber ein Gerät gefällt, erstellt er eine device-Struktur und gibt diese zurück an die CDI-Implementierung.
run_drivers gehört nicht mehr dazu, wenn ich mich richtig erinnere. Und ich glaube die driver_register-Funktionen sind auch veraltet, das geht neu mit dem CDI_DRIVER-Makro.

Wo werden eigentlich die gefundenen Blockdevices den einzelnen Dateisystemen zugeordnet oder in Partitionen gesplittet?
Gerade für die Dateisysteme vermisse ich eine Funktion die einem Dateisystemtreiber die ersten paar Sektoren einer Partition oder eines Blockdevices (falls nicht partitioniert) übergibt damit das Dateisystem erst einmal prüfen kann ob es sich überhaupt dafür zuständig fühlt und dann vom CDI eine neue Instanz gestartet wird.
Das zuordnen der Dateisystemen zum Blockgerät hat nichts mit CDI zu tun, das ist Sache der Implementierung.

Wie kann sich der IP-Stack an CDI anmelden?
Zumindest bei einem Micro-Kernel-OS ist er ja nicht direkt Bestandteil des eigentlichen OS selber. Obwohl man auch sagen könnte das bei einem richtigen Micro-Kernel-OS der Kernel noch nicht mal weiß das CDI überhaupt existiert.
Der IP-Stack meldet sich garnicht an CDI an. Ich würde das eher so implementieren, dass sich die CDI/net-Implementierung halt beim Netzwerk-Stack anmeldet, und die entsprechenden Geräte meldet, und dann natürlich auch die Pakete durchstellt.

Bei den PCI-Geräten ist immer nur ein IRQ erlaubt, warum?
Könnte man die IRQs nicht auch als Ressource betrachten, so wie Speicherbereiche und I/O-Port-Bereiche?
Mir ist klar das in aktuellen PCs kaum ein Gerät mehr als einen IRQ benutzt aber viele (wie AHCI) sind zu mehr fähig.
Weil bisher niemand mehr gebraucht hat? Es dürfte ja relativ offensichtlich sein, dass CDI bis jetzt eher nicht auf vollständigkeit sondern eher auf Einfachheit ausgerichtet ist.

Ein bisschen mehr Beschreibung des "Drumherum" wäre nicht schlecht.
Wenn CDI nur eine Sammlung von Funktionsprototypen ist dann ist sein Nutzwert IMHO noch recht gering, es sollte auch ein Konzept existieren wie man CDI benutzen muss damit es einem auch wirklich was hilft.
CDI ist halt die Definition einer Schnittstelle, dazu gehören halt die Funktions-Prototypen und die Typen. Sinn des ganzen ist ja genau, dass die Schnittstelle nicht vorschreibt wie sie implementiert/benutzt werden _muss_, um die nötige Flexibilität zu erhalten sie problemlos unter verschiedenen Betriebssystem-Typen laufen zu lassen.

 

Einloggen