Von diesen drei Faktoren, die Sie aufgelistet haben, ist nur die erste tatsächlich korrekt. Wie für den Rest - nicht wirklich. Es ist möglich, dass ein Benutzer-Space-Code DMA-Operationen ausführt - kein Problem damit. Es gibt viele Hardware-Appliance-Unternehmen, die diese Technik in ihren Produkten einsetzen. Es ist auch möglich, eine interruptgesteuerte Benutzerraumanwendung zu verwenden, selbst wenn alle E/A mit einem vollständigen Kernel-Bypass ausgeführt werden. Natürlich ist es nicht so einfach, einfach eine mmap() auf /dev/mem zu tun.
Sie müssten einen minimalen Teil Ihres Treibers im Kernel haben - das ist notwendig, um Ihrem Benutzer einen minimalen Speicherplatz zu verschaffen, den er vom Kernel benötigt (denn wenn Sie darüber nachdenken - /dev/mem ist auch von einem Zeichengerätetreiber unterstützt).
Für DMA ist es eigentlich zu einfach - alles, was Sie tun müssen, ist die mmap Anforderung zu behandeln und einen DMA-Puffer in den Benutzerraum abzubilden. Für Interrupts - es ist ein wenig komplizierter, der Interrupt muss vom Kernel gehandhabt werden, egal was, aber der Kernel macht vielleicht keine Arbeit und weckt nur den Prozess auf, der zB epoll_wait() aufruft. Ein anderer Ansatz besteht darin, ein Signal an den Prozess zu senden, wie es DOSEMU getan hat, aber das ist sehr langsam und wird nicht empfohlen.
Was Ihre eigentliche Frage betrifft, ist ein Faktor, den Sie beachten sollten, die gemeinsame Nutzung von Ressourcen. Solange Sie ein Gerät nicht für mehrere Anwendungen freigeben müssen und nichts anderes im Benutzerbereich möglich ist, wählen Sie den Benutzerbereich aus. Sie werden wahrscheinlich während des Entwicklungszyklus viel Zeit sparen, da das Schreiben von Benutzercode sehr einfach ist. Wenn jedoch zwei oder mehr Anwendungen das Gerät (oder seine Ressourcen) gemeinsam nutzen müssen, ist es wahrscheinlich, dass Sie viel Zeit dafür aufwenden werden - stellen Sie sich einfach vor, dass mehrere Prozesse gleichzeitig ablaufen, abstürzen, gleichzeitig Speicher ablegen (usw.) Und schließlich wird IPC im Allgemeinen über den Kernel ausgeführt, sodass, wenn die Anwendung mit dem "Sprechen" beginnen müsste, die Leistung stark beeinträchtigt sein könnte. Für einige performancekritische Anwendungen wird das zwar immer noch im wirklichen Leben gemacht, aber ich möchte nicht auf diese Details eingehen.
Ein weiterer Faktor ist die Kernel-Infrastruktur. Nehmen wir an, Sie möchten einen Netzwerkgerätetreiber schreiben. Das ist kein Problem, es im Benutzerraum zu tun. Wenn Sie dies tun, müssen Sie jedoch auch einen vollständigen Netzwerkstapel schreiben, da es nicht möglich ist, Linux-Standardbenutzernamen zu verwenden, der im Kernel vorhanden ist.
Ich würde sagen, gehen Sie für Benutzerraum, wenn es möglich ist und die Menge an Aufwand, um Dinge zu arbeiten, ist weniger als das Schreiben eines Kernel-Treibers und im Hinterkopf, dass es eines Tages notwendig sein könnte, Code in den Kernel zu verschieben . Tatsächlich ist es eine gängige Praxis, denselben Code sowohl für den Benutzerraum als auch für den Kernelraum zu kompilieren, je nachdem, ob ein Makro definiert ist oder nicht, da das Testen im Benutzerbereich viel angenehmer ist.
Sicherheit: Dateiberechtigungen des Geräteknotens steuern, welche Benutzer das Gerät öffnen/lesen/schreiben können. Dateioperationen verweigern oder erlauben gleichzeitige Operationen. – sawdust
Die Entscheidung kann stark davon abhängen, was Sie PWMing sind und welche Hardware verwenden. –