Wo programmiert es sich am komfortabelsten?
-
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?
-
Was war jetzt eigentlich die Frage?
Ob man unter Windows bzw. MacOS genauso komfortabel Treiber entwickeln kann wie unter Linux?
Ich würde mal behaupten das dir das nur jemand sagen der schon für alle 3 Plattformen einen Treiber entwickelt hat.
-
Hacker schrieb:
Korrigiere mich, wenn ich etwas falsch verstanden hab; Treiber sind doch in mikro-kerneln im User-Space?
Jein, bei jeden System muss man zwischen Kernel-Space- und User-Space-Treiber differenzeren, während Mirkokernel bestrebt sogut wie alles in den User-Space zu verlagern, exestieren dennoch auch Kernel-Space-Treiber. Linux beispielweise will monolitsch während aber der Grafikkarten-Treiber doch im User-Space lief - heute dunno vielleicht hat sich das geändert. Außerdem gibst noch Hybrid-System wie MacOSX, Windows (NT-based) und Beos (aka Haiku).
-
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.
jede Menge POSIX-Schnittstellen sind aber im Kernel-Space.
-
Steffo 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.
jede Menge POSIX-Schnittstellen sind aber im Kernel-Space.
Und geben Garantien an Userspace-Code ... wieso nicht einfach die darunterliegenden Funktionen direkt nutzen?
-
Ethon schrieb:
Und geben Garantien an Userspace-Code ...
Wie meinst du das mit den Garantien?
wieso nicht einfach die darunterliegenden Funktionen direkt nutzen?
Weil die manchmal etwas komplexer sind und sich auch häufiger ändern und außerdem weniger portabel sind.
-
mit einer Tasse Kaffe, und einer Packung Kekse, schlechtem Wetter draußen, guten greifbaren Dokumentationen, einem Buch zum Nachschlagen, dem Gefühl etwas wirklich brauchbares zu programmieren, dem entsprechendem Know How im Hinterkopf, Magen != 0 , praktischem Editor, schönem Interpreter, Schmierblättern, -
Und ich würde jetzt auch nicht sagen, dass die Visual Studio Umgebung und die Stabilität des Desktops von Windows das Programmieren behindert.
Debugger und Disassemblerangebot ist für Windows auch irgendwie besser. Wer will, kann ja grundlegende Sachen immer noch auf Windows 95 + Softice programmieren.
Mit Java Tools (u.a. ME) habe ich unter Windows auch weniger Probleme als unter Linux.
Eine gute Zukunftsrichtung wäre sicherlich, FPGAs oder neuere Hardware intern beschleunigt mit Haskell programmieren zu können.
-
crunch crunch schrieb:
Eine gute Zukunftsrichtung wäre sicherlich, FPGAs oder neuere Hardware intern beschleunigt mit Haskell programmieren zu können.
Lol.
-
Steffo 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.
jede Menge POSIX-Schnittstellen sind aber im Kernel-Space.
Welche POSIX Schnittstellen sind im Kernel Space? Die sind vielleicht (teilweise) im Kernel implementiert, aber da kannst du sie sicher nicht benutzen. Kernel Module funktionieren einfach ganz anders (ja, es gibt auch User Space Treiber, und die Aussage von Zeus wegen Grafikkartentreibern ist immer noch richtig, aber 99% der Treiber laufen im Kernel Space). Du kannst da nichts wegabstrahieren oder "bequem" programmieren. Du musst einfach ganz genau wissen, was du tust. Und da gehört auch oft dazu, dass man irgendwelche Datenstrukturen direkt manipuliert, die sich tatsächlich öfters mal ändern können. Es gibt für Linux nicht mal einen wirklich brauchbaren/offiziellen Kerneldebugger. Es gibt auch eine Aussage von Linus Torvalds zu dem Thema. Läuft in etwa darauf hinaus, dass er nichts von irgendwelchen Kernel Debuggern hören will und Leute die sowas brauchen sie eh Trottel, die keine Ahnung haben, was sie tun, und die sollen nicht in seinem Kernel rumpfuschen. Und da willst du eine Posix API, die dir was abstrahiert und portabel macht ^^ Träum weiter.
-
knivil schrieb:
crunch crunch schrieb:
Eine gute Zukunftsrichtung wäre sicherlich, FPGAs oder neuere Hardware intern beschleunigt mit Haskell programmieren zu können.
Lol.
-> hardware beschleunigte Java-Arms
-> http://www.drdobbs.com/jvm/232901227auch Lol aber eher *hysterisch-maniacally*
Ständig unter latenter Patentklagenandrohung u.ä. zu programmieren ist nämlich alles andere als komfortabel