Am Anfang stellt sich die Frage, welche Nebenläufigkeiten in den Gerätetreibern existieren können. Es ist hier leider nicht möglich, eine allgemeingültige Antwort zu geben, da diese stark von der Geräteklasse abhängig ist. Soll also eine Lösung geschaffen werden, die jede mögliche Anforderung aller Treiber erfüllt, ist es schwer eine Ein-Thread Lösung (wie in [Sta96,Meh96]) zu entwerfen.
Potentiell nebenläufig sind zuerst alle Nutzeranfragen der Prozeßebene. Hier ist es Aufgabe des Treibers, Sperren zu nutzen bzw. jeweils nur eine Anfrage zuzulassen. Es ist auch möglich, daß ein Gerätetreiber mehrere Schnittstellen exportiert, welche auch parallel nutzbar sein sollen. Ein Beispiel sind Treiber für Soundkarten, die neben einer Schnittstelle für den Signalprozessor (PCM-Daten) auch eine solche für den Mixer-Chip exportieren.
Neben diesen Aktivitäten treten Hardware-Interrupts und zugehörige deferred activities auf, die auch als potentiell nebenläufig zu betrachten sind. Es ergibt sich folgende Struktur:
Threads für Nutzerschnittstellen
Vorteil dieser Struktur ist die Möglichkeit, jeder Aktivität eine eigene Thread-Priorität zuordnen zu können. So kann der Interrupt-Thread sofort auf auftretende Unterbrechungen reagieren und am Gerät die Verarbeitung anzeigen, um eine kleine Latenz zu erreichen. Die deferred activities sind weniger hoch priorisiert und von der ISR verdrängbar. Ähnlich verhält es sich mit den Schnittstellen-Threads, welche die geringste Priorität besitzen.
Dies emuliert das Verhalten im Linuxkern ziemlich genau, demnach eine Prozeß-Aktivität den Kern erst nach vollständiger Abarbeitung anstehender Aufgaben verläßt.
Der Nachteil ist die erhöhte Anzahl von L4-Threads im Vergleich zu den früheren Lösungen, deren Mehraufwand aber nicht sehr groß sein sollte. Außerdem unterstützen alle Gerätetreiber aus Linux inherent Nebenläufigkeiten, was auch in Hinblick auf SMP-Fiasco-Systeme interessant erscheint.