Was ist denn der Unterschied zwischen einem Treiber der FUSE nutzt und einem normalen Treiber? Der eine läuft im Userspace der andere im Kernelspace aber was heisst das konkret?
Alle im Kernel Module und Treiber laufen im selben Addressraum, dadurch kann ein fehlerhafter Treiber die gesamtstabilität des Systems beeinflussen. Läuft der Treiber im Userspace, ist er ein ganz normaler Prozess, der, wenn er abstürzt nicht das gesamte System mitreisst. Ein weiterer Vorteil ist, dass es für Leute die die Kernel Internas und APIs nicht gut kennen jetzt viel einfacher ist einen Treiber zu entwickeln. Auch das Debuggen eines Userspace Prozesses ist viel einfacher.
Noch eine weitere Anmerkung. Immer wieder wird der Linux Kernel für seine monolithische Struktur kritisiert, dass also alle wichtigen Systemdienste wie Gerätetreiber, Dateisystemtreiber, Speicherverwaltung etc. als Bestandteil des Kernels laufen. Das andere Konzept sind s.g. Mirco Kernel wie L4, Mach etc. Hier kümmert sich der Kernel um das Aufsetzen des Systems, empfangen von Interrupts und stellt Möglichkeiten zur Kommunikation zwischen Prozessen (Messages) zur verfügung. Alles weitere wird dann von Userspace Prozessen, häufig dann auch Server genannt, erledigt. Diesem Konzept öffnet sich der Linux kernel nun auch.
Man muss sich aber dafür eventuell so einiges an Stack anlegen. (Bei Tail-Recursion nicht, aber wenn das möglich ist, wird man es in C sowieso nicht rekursiv machen.)
Ein monolithischer Kernel ist als einziger fetter Prozess zusehen der natürlich abstürzen/hängen kann, wenn Teile von ihm fehlerhaft programmiert sind. Wie ein normales Programm eben.
Es gibt für so einen Kernel nicht den Speicherschutz den der Kernel für die Programme die "auf ihm laufen" anbietet: Ein Programm bekommt seinen eigenen Speicherbereich und kann nur darin "herumpfuschen", d.h. fehlerhafte Programme beeinflussen keine anderen. In Windows 98 hatte der Kernel z.B. keinen Speicherschutz, deswegen konnten Programme andere mitreißen, wenn sie etwa unabsichtlich in deren Speicherbereich geschrieben hatten.
Mikrokernel wie L4 gelten schon immer als eigentlich elegantere Lösung, da die gesamte Funktionalität modularisiert ist und das viele Vorteile bietet. Der einzige große Nachteil an Mikrokerneln ist, dass IPC, also die Inter-Prozess-Kommunikation, d.h. die Nachrichten zwischen den Servern/Modulen des Kernels prinzipbedingt langsamer ist als die Kommunikation innerhalb eines großes Prozesses wie einem monolithischen Kernel.
Na ja, ich habe ein bisschen mit FUSE rumexperimentiert und es als unglaublichen CPU-Fresser empfunden. Die Context Switches sind nicht nur theoretisch ein Flaschenhals. Reine µKernel sind deshalb nicht für den Desktop-Betrieb geeignet.
"Die Context Switches sind nicht nur theoretisch ein Flaschenhals. Reine µKerne sind deshalb nicht für den Desktop-Betrieb geeignet." Ich glaube, daß man dafür auch HW unterstützung einbauen kann, dann sollte dieses Problem behoben sein, aber wer macht das?
Bei richtigen Mikrokerneln liegt der Overhead deutlich unter 10%. Beispiel USB unter L4: "[...] DDEUSB [...] is able to offer access to usb with an overhead of 2.4 percent compared to L4 Linux and 6.4 percent compared to native Linux"
Der eine läuft im Userspace der andere im Kernelspace aber was heisst das konkret?
PS: Ein neues Foto von Linus!
Gruss
Markus
die z.B. vom NTFS-Treiber benutzt werden müssen, werden
durch FUSE ermöglicht.
(Bei Tail-Recursion nicht, aber wenn das möglich ist, wird man es in C sowieso nicht rekursiv machen.)
Es gibt für so einen Kernel nicht den Speicherschutz den der Kernel für die Programme die "auf ihm laufen" anbietet: Ein Programm bekommt seinen eigenen Speicherbereich und kann nur darin "herumpfuschen", d.h. fehlerhafte Programme beeinflussen keine anderen. In Windows 98 hatte der Kernel z.B. keinen Speicherschutz, deswegen konnten Programme andere mitreißen, wenn sie etwa unabsichtlich in deren Speicherbereich geschrieben hatten.
Mikrokernel wie L4 gelten schon immer als eigentlich elegantere Lösung, da die gesamte Funktionalität modularisiert ist und das viele Vorteile bietet. Der einzige große Nachteil an Mikrokerneln ist, dass IPC, also die Inter-Prozess-Kommunikation, d.h. die Nachrichten zwischen den Servern/Modulen des Kernels prinzipbedingt langsamer ist als die Kommunikation innerhalb eines großes Prozesses wie einem monolithischen Kernel.
Ich glaube, daß man dafür auch HW unterstützung einbauen kann, dann sollte dieses Problem behoben sein, aber wer macht das?
Beispiel USB unter L4:
"[...] DDEUSB [...] is able to offer access to usb with an overhead of 2.4 percent compared to
L4 Linux and 6.4 percent compared to native Linux"
Quelle:
http://os.inf.tu-dresden.de/papers_ps/vogt-beleg.pdf