Wo programmiert es sich am komfortabelsten?
-
cooky451 schrieb:
Steffo schrieb:
Z. B. Treiber entwickeln.
Dann sag das doch. Anstatt also Äpfel mit Birnen zu vergleichen, vergleiche doch die Schnittstelle des OS zur Treiberentwicklung. Dann ist das zumindest ansatzweise sinnvoll..
Ich hab die ganze Zeit von OS-Schnittstellen geredet...
-
Steffo schrieb:
Ich hab die ganze Zeit von OS-Schnittstellen geredet...
Du denkst jede OS Schnittstelle ist zur Treiberentwicklung gedacht?
-
Steffo schrieb:
cooky451 schrieb:
Steffo schrieb:
Z. B. Treiber entwickeln.
Dann sag das doch. Anstatt also Äpfel mit Birnen zu vergleichen, vergleiche doch die Schnittstelle des OS zur Treiberentwicklung. Dann ist das zumindest ansatzweise sinnvoll..
Ich hab die ganze Zeit von OS-Schnittstellen geredet...
OS-Schnittstellen ist die Menge aller Schnittstelle, also alles nutzt es! Deswegen ist das nicht eingrenzten. Du meinst Kernel-Schnittstellen?
-
OK, da ist was dran.
EDIT: Ja, Kernel-Schnittstellen.
-
Du denkst jede Kernel Schnittstelle ist zur Treiberentwicklung gedacht?
-
Steffo schrieb:
OK, da ist was dran.
EDIT: Ja, Kernel-Schnittstellen.
Sind alle Kernel-Schnittstellen für Treiberentwicklung da? Wie viele Leute in Deutschland entwickeln Treiber für gleichzeitig mehreren Plattformen? ;o
-
Ne, aber man muss Kernelschnittstellen ansteuern, um Treiber für ein OS zu programmieren.
-
Fork gehört aber nicht zur Schnittstelle zur Treiberentwicklung. Kennst du entsprechende Schnittstellen? Ich finde die Linux Schnittstelle leichter für den Einstieg. Die Windows Schnittstelle ist pseudoobjektorientiert. Ich find sie aber sehr komplex, bin da nie gut reingekommen.
@cooky451: Ich meinte das so, dass es nicht primär darauf ankommt, wie komfortabel die Schnittstelle ist (meist nutzt man eh irgendwelche Bibliotheken, die das ganze verstecken), andere Aspekte sind wichtiger. Und wenn die Schnittstelle auch noch abwärtskompatibel bleiben muss, dann ist klar, dass das ganze ziemlich ausartet.
-
Mechanics schrieb:
Fork gehört aber nicht zur Schnittstelle zur Treiberentwicklung.
Inwiefern? Gibt es keine Treiber, die fork benutzen?
Kennst du entsprechende Schnittstellen?
Da bin ich ehrlich gesagr überfragt. Treiberprogrammierung habe ich noch nicht gemacht, wohl aber POSIX- und System-V-Schnittstellen benutzt.
-
Steffo schrieb:
Mechanics schrieb:
Fork gehört aber nicht zur Schnittstelle zur Treiberentwicklung.
Inwiefern? Gibt es keine Treiber, die fork benutzen?
Nein, ganz andere Welt, hat damit überhaupt nichts zu tun.
-
Steffo schrieb:
Mechanics schrieb:
Fork gehört aber nicht zur Schnittstelle zur Treiberentwicklung.
Inwiefern? Gibt es keine Treiber, die fork benutzen?
Im Regelfall geht es beim ein Treiber um Signalverarbeitung die für das Betriebssystem abstrahiert wird. Neben den Plattform-spezifischen Details, steht ansonst weitere API vom System zu nutzen. Aber die Nutzung von Instrumenten des Prozessmanagement - höchstwahrscheinlich sehr selten. Gewinnst du nebenläufige Ansteuerung eines Busses - Beispiel zwei Treiberprozesse steuern die Grafikkarten über ein seriellen Bus(PCIe)? Ich weiße es nicht in diesen Bereich bin ich ein Laie.
-
Man kann im Kernel nichts forken. Ein Treiber ist kein Prozess. Da gibts ganz andere Konzepte, wie Tasklets und work queues. Ganz andere Speichverwaltung etc. Eben eine komplett eigenständige API. Die userspace Api kann man da nicht benutzen.
-
Mechanics schrieb:
Man kann im Kernel nichts forken. Ein Treiber ist kein Prozess. Da gibts ganz andere Konzepte, wie Tasklets und work queues. Ganz andere Speichverwaltung etc. Eben eine komplett eigenständige API. Die userspace Api kann man da nicht benutzen.
Sorry das ist Betriebssystem-spezifisch, hab doch gestern in der Macosx im KernelDev-Teil gelesen, dass die Treiberentwickler auf die ganze POSIX zugreifen können.
-
Am komfortabelsten programmiert es sich so high-level wie möglich
-
Mit Hoehensonne und Sonnenschutzcreme sozusagen ...
-
Zeus schrieb:
Mechanics schrieb:
Man kann im Kernel nichts forken. Ein Treiber ist kein Prozess. Da gibts ganz andere Konzepte, wie Tasklets und work queues. Ganz andere Speichverwaltung etc. Eben eine komplett eigenständige API. Die userspace Api kann man da nicht benutzen.
Sorry das ist Betriebssystem-spezifisch, hab doch gestern in der Macosx im KernelDev-Teil gelesen, dass die Treiberentwickler auf die ganze POSIX zugreifen können.
Was aber Bullshit ist. Userspace-APIs im Kernel sind Bullshit.
-
Ethon schrieb:
Zeus schrieb:
Mechanics schrieb:
Man kann im Kernel nichts forken. Ein Treiber ist kein Prozess. Da gibts ganz andere Konzepte, wie Tasklets und work queues. Ganz andere Speichverwaltung etc. Eben eine komplett eigenständige API. Die userspace Api kann man da nicht benutzen.
Sorry das ist Betriebssystem-spezifisch, hab doch gestern in der Macosx im KernelDev-Teil gelesen, dass die Treiberentwickler auf die ganze POSIX zugreifen können.
Was aber Bullshit ist. Userspace-APIs im Kernel sind Bullshit.
Wer hat etwas von im Kernel gesagt?
-
"KernelDev" ... "Treiberentwicklung" ... ?
-
Ethon schrieb:
"KernelDev" ... "Treiberentwicklung" ... ?
Treiber können nicht im User-Space sein?
-
Zeus schrieb:
Ethon schrieb:
"KernelDev" ... "Treiberentwicklung" ... ?
Treiber können nicht im User-Space sein?
Korrigiere mich, wenn ich etwas falsch verstanden hab; Treiber sind doch in mikro-kerneln im User-Space?