Legend wrote:
Tell the driver applications via IPC that an IRQ has happended, this will receive the IRQ in ring 0 (in your kernel I guess), but the real processing happens in ring 3.
Agree, this can be done... however, you will dramatically decrease the throughput you can achieve on the device. Take for instance the disk driver. If you're able to emit the next "read sector" command right after being notified of the previous command completion, you're working at higher speed.
With a ring-3 driver, you'll have to wait for at least one context switch before this can be done (assuming that you don't have in addition to wait for some process to complete its execution before you get the notification)
Quote:
However, you can protect yourself for example from the sound driver, network card driver, graphics card driver etc.
possibly, yes, though those drivers may have some 'DMA' programming features, and if you submit corrupted data to the DMA registers, you'll screw up your system's memory ... You can hardly enforce checks on this without a knowledge of the device at kernel-level
Quote:
And don't forget that Linux does TCP/IP in the kernel, too, which directly does not need any hardware access, so it would already be better to get that on ring 3.
Indeed, TCP/IP doesn't need hardware access. However, it's a demultiplexing component towards several processes, thus having it as a user process would imply additionnal switch.
Concerning my own project, i'm trying to put reasonnable amount of work at kernel level and keep the "gross" job as user-level. This means for instance that IP forwarding would occur at user-level but that user-mode could have the opportunity to install filters for kernel-level NIC driver so that the kernel-level code can know (without understanding the whole TCP/IP stack) who's the packet recipient.