Wo programmiert es sich am komfortabelsten?

[Zeus]

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).

[Gast]

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.

[Ethon]

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?

[Gast]

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.

[crunch crunch]

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.

[knivil]

crunch crunch schrieb:

Eine gute Zukunftsrichtung wäre sicherlich, FPGAs oder neuere Hardware intern beschleunigt mit Haskell programmieren zu können.

Lol.

[Mechanics]

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.

[crunch crunch]

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/232901227

auch Lol aber eher *hysterisch-maniacally*
Ständig unter latenter Patentklagenandrohung u.ä. zu programmieren ist nämlich alles andere als komfortabel

[dot]

Steffo schrieb:

Mich würde mal interessieren, wie komfortabel es sich unter anderen OS wie Windows, Mac OS X, aber auch BeOS programmiert.

Dank Visual Studio programmiert es sich unter Windows imo mit großem Abstand am komfortabelsten.

Steffo schrieb:

Wenn ich mir anschaue, wie einfach es unter Linux ist einen neuen Prozess mittels fork() zu erstellen und das dann mit Windows vergleiche, bin ich froh, dass ich nichts mit der WinAPI machen muss.

Also ich weiß ja nicht was du gegen CreateProcess() hast, aber wenn du mich fragst, dann ist fork() schon rein vom Konzept her völlig kaputt...

[Ethon]

dot schrieb:

Steffo schrieb:

Mich würde mal interessieren, wie komfortabel es sich unter anderen OS wie Windows, Mac OS X, aber auch BeOS programmiert.

Dank Visual Studio programmiert es sich unter Windows imo mit großem Abstand am komfortabelsten.

Betonung auf imo .

dot schrieb:

Steffo schrieb:

Wenn ich mir anschaue, wie einfach es unter Linux ist einen neuen Prozess mittels fork() zu erstellen und das dann mit Windows vergleiche, bin ich froh, dass ich nichts mit der WinAPI machen muss.

Also ich weiß ja nicht was du gegen CreateProcess() hast, aber wenn du mich fragst, dann ist fork() schon rein vom Konzept her völlig kaputt...

Wieso?

[knivil]

dot schrieb:

wenn du mich fragst, dann ist fork() schon rein vom Konzept her völlig kaputt...

10 Parameter vs. 0 Parameter. Ich finde fork() sehr schoen. Aber vielleicht magst du etwas ausfuehrlicher antworten.

[dot]

Allein die Tatsache dass so etwas wie exec() existiert, spricht imo schon ziemlich für sich. Man will eben in der Regel nicht forken, sondern sowas wie CreateProcess(). Aber anstatt einer ordentlichen Lösung für das tatsächliche Problem, gibts eben einen Hack wie exec()...

[Ethon]

Naja, Hack ... finde es eigentlich ziemlich elegant gelöst.

[314159265358979]

dot schrieb:

Man will eben in der Regel nicht forken, sondern sowas wie CreateProcess().

dude qtf, so obv wrong

[dot]

314159265358979 schrieb:

dot schrieb:

Man will eben in der Regel nicht forken, sondern sowas wie CreateProcess().

dude qtf, so obv wrong

Ich sag nicht dass fork() rein prinzipiell schlecht ist. Vor allem in Zeiten da es noch keine Threads gab sicherlich eine praktische und elegante Lösung für viele Dinge. Aber sag mir doch mal bitte, wie oft du bisher fork() aufgerufen hast ohne gleich darauf ein exec() zu machen?

[Bashar]

dot schrieb:

Aber sag mir doch mal bitte, wie oft du bisher fork() aufgerufen hast ohne gleich darauf ein exec() zu machen?

Immer wenn man dazwischen noch irgendwelche Pipes verkabeln will beispielsweise. Das Unix-Konzept basiert halt darauf, elementare Operationen zu identifizieren und zu komponieren; während das Windows-Konzept darin besteht, die häufigsten Fälle bequem zu machen und den Rest irgendwie ... nicht so bequem. Das zieht sich durch jede MS-API, die ich bisher gesehen habe.

[dot]

Jap, ich hab grad etwas drüber nachgedacht und muss zugeben, dass es doch gar nicht sooo verkehrt ist wie ich immer gedacht hab...ich hatte nur einmal das Vergnüngen, fork() und exec() selbst zu implementieren und seit damals fühlte sich beides für mich irgendwie so falsch an, weil fork() und exec() für mich bedeutet: Page Directory kopieren, Handles duplizieren und haufenweise anderen Kram, nur um das alles dann gleich wieder wegzuwerfen...

[Gast]

dot schrieb:

Jap, ich hab grad etwas drüber nachgedacht und muss zugeben, dass es doch gar nicht sooo verkehrt ist wie ich immer gedacht hab...ich hatte nur einmal das Vergnüngen, fork() und exec() selbst zu implementieren und seit damals fühlte sich beides für mich irgendwie so falsch an, weil fork() und exec() für mich bedeutet: Page Directory kopieren, Handles duplizieren und haufenweise anderen Kram, nur um das alles dann gleich wieder wegzuwerfen...

fork ist unter Linux nicht teuer, wenn du gleich danach exec aufrust:

Under Linux, fork() is implemented using copy-on-write pages, so the only penalty that it incurs is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.

[dot]

Steffo schrieb:

fork ist unter Linux nicht teuer, wenn du gleich danach exec aufrust:

Das ist mir natürlich bewusst. Das Page Directory muss aber dennoch (potentiell unnötigerweise) kopiert werden, auch wenn man nicht sofort die Pages kopiert.

fork() und CreateProcess() sind imo jedenfalls zwei fundamental unterschiedliche Dinge, die jeweils eigene Syscalls sein sollten. Weder sind fork() und exec() elementare Operationen in einem CreateProcess(), noch umgekehrt. fork() und exec() ist imo lediglich eine Approximation eines CreateProcess(), aber eben nicht völlig äquivalent.

[Fast2_unreg]

Eben das Duplizieren der Daten fand ich auch schon immer falsch, obwohl es durch Kopieren bei Bedarf immerhin nicht ganz so schlimm ist wie es ohne wäre. Trotzdem frage ich mich, wie man damals auf die Idee kam, es wäre besser den gesamten Prozess zu Klonen statt einen neuen aufzusetzen. (Irgendwo habe ich auch mal etwas darüber gelesen, aber das weiß ich nicht mehr)
Für mich ist gerade das Anlegen eines neuen Prozesses ein Teil des Kopierens eines Prozesses, also wenn schon, müsste man meiner Meinung nach eher CreateProcess den Vorzug geben.