> unless you're doing weird shared-memory things in userspace
Shared-memory things in userspace, i.e. buffers shared between 2 distinct user processes are no weirder than buffers that are shared between a user process and a kernel-mode driver. In both cases the buffers cannot be accessed by third parties.
Moreover, the transfer of data between 2 processes through a shared buffer can be done without any context switch (which could be slow), if the 2 processes are executed on distinct cores. Therefore having the network device driver as a distinct process does not have to cause any reduction in performance, if the means for inter-process communication are chosen wisely.
For any device driver that is implemented as a user process, the kernel can enable direct access to any I/O ports and memory-mapped I/O areas that are needed by the device, so the device driver can work in user mode without requiring any context switches.
Such direct I/O access cannot be enabled for ordinary processes, because those are not trusted enough and also because the direct I/O access could be enabled only for a single process at a time.
A dedicated device driver process solves both the trust problem and the multiple access problem equally well as a kernel-mode driver.
Things are more complicated. You can indeed have a very fast network driver in userspace (in fact for many use cases userspace networking is faster than the kernel). But where do you put the rest of the network stack?
Shared-memory things in userspace, i.e. buffers shared between 2 distinct user processes are no weirder than buffers that are shared between a user process and a kernel-mode driver. In both cases the buffers cannot be accessed by third parties.
Moreover, the transfer of data between 2 processes through a shared buffer can be done without any context switch (which could be slow), if the 2 processes are executed on distinct cores. Therefore having the network device driver as a distinct process does not have to cause any reduction in performance, if the means for inter-process communication are chosen wisely.
For any device driver that is implemented as a user process, the kernel can enable direct access to any I/O ports and memory-mapped I/O areas that are needed by the device, so the device driver can work in user mode without requiring any context switches.
Such direct I/O access cannot be enabled for ordinary processes, because those are not trusted enough and also because the direct I/O access could be enabled only for a single process at a time.
A dedicated device driver process solves both the trust problem and the multiple access problem equally well as a kernel-mode driver.