3 ms·

Drivers in userspace is not particularly microkernelly - most of the major monolithic kernels have supported this to some degree or another for years (it is eas

Drivers in userspace is not particularly microkernelly - most of the major monolithic kernels have supported this to some degree or another for years (it is easy in principle, just transmit I/O requests to userspace servers over some channel) while many historic microkernels (see e.g. Mach 3) did not do it. It hardly changes the architecture of the system at all. It is moving the higher-level things into userland that is the harder problem, and the one that has been challenging for microkernels to do well.

vacuity 2y ago
People should stop bringing up Mach so much. It should never have been the poster child for microkernels. It's poisoned the discourse when there are plenty of alternative examples. Granted, Mach also did some good work in the space, but its shortcomings are emphasized as if they reflect the whole field. More to the point, drivers in userspace is an important distinction between "pure" monolithic kernels and microkernels: the former is optimizing for performance and the latter is optimizing for robustness. It's not about ease of implementation for either. It's quite meaningful to shift on the axis nowadays: it represents a critical pragmatic decision (notice purity is irrelevant). You're right that "higher-level things" such as the networking stack or filesystem are also crucial to the discussion. I think here, too, ease of implementation is not relevant, though.
torginus 2y ago
Isn't it common to run OSes on desktop/server environment inside hypervisors? That means the OS itself can be transparently virtualized or preempted, and access to physical hardware can be transparently passed to the virtualized OSes. This can be accomplished today with minimal impact to performance on user experience. The fact that this can be done with OS code not explicitly designed for this signals to me that there are no roadblocks to having a high-performing general purpose microkernel running our computers.
- vacuity 2y ago
  This leads to big units of code, namely multiple OSes, whereas the ideal is being able to use as finely granular units as developers are able to stomach. For example, Xen can work around the issue of device drivers by hosting a minimal OS instance that has drivers, but it is better to be able to run drivers as individual processes. This reduces code duplication and performance overhead.
  - torginus 2y ago
    You're absolutely right but I was making the point that there's demonstrably no significant downsides to running driver/kernel code in less privileged mode, rather than Ring 0.

vacuity 2y ago

People should stop bringing up Mach so much. It should never have been the poster child for microkernels. It's poisoned the discourse when there are plenty of alternative examples. Granted, Mach also did some good work in the space, but its shortcomings are emphasized as if they reflect the whole field. More to the point, drivers in userspace is an important distinction between "pure" monolithic kernels and microkernels: the former is optimizing for performance and the latter is optimizing for robustness. It's not about ease of implementation for either. It's quite meaningful to shift on the axis nowadays: it represents a critical pragmatic decision (notice purity is irrelevant). You're right that "higher-level things" such as the networking stack or filesystem are also crucial to the discussion. I think here, too, ease of implementation is not relevant, though.

torginus 2y ago

Isn't it common to run OSes on desktop/server environment inside hypervisors? That means the OS itself can be transparently virtualized or preempted, and access to physical hardware can be transparently passed to the virtualized OSes. This can be accomplished today with minimal impact to performance on user experience. The fact that this can be done with OS code not explicitly designed for this signals to me that there are no roadblocks to having a high-performing general purpose microkernel running our computers.

vacuity 2y ago
This leads to big units of code, namely multiple OSes, whereas the ideal is being able to use as finely granular units as developers are able to stomach. For example, Xen can work around the issue of device drivers by hosting a minimal OS instance that has drivers, but it is better to be able to run drivers as individual processes. This reduces code duplication and performance overhead.
- torginus 2y ago
  You're absolutely right but I was making the point that there's demonstrably no significant downsides to running driver/kernel code in less privileged mode, rather than Ring 0.