3 ms·

> Tanenbaum was theoraticaly correct. He was only correct in a world where programmer and cpu time is free and infinite.

by saati 2y ago

marcosdumay 2y ago
Care to elaborate how working in a microkernel instead of a monolithic one wastes programmer time? Because AFAIK, every single evidence we have points the exact opposite. Also, microkernels only waste CPU time because modern CPUs go to great lengths to punish them, for no comparable gain for monolithic kernels, apparently because that's the design that they always used.
IX-103 2y ago
I understand CPU time, as micro-kernels tend to be less efficient, but why do you include programmer time? My understanding is that it's easier to develop drivers for a micro-kernel. If you look at FUSE (filesystem in user space), and NUSE (network in user space), as well as the work with user-space graphics drivers, you see that developers are able more rapidly implement a working driver and solve more complicated problems in user space than in kernel space. These essentially treat Linux as a micro-kernel, moving driver code out of the kernel.
- ryao 2y ago
  A microkernel only gives you scheduling, IPC and virtual memory. You and others get to implement everything else on top of that. That means there are no NUSE or FUSE interfaces and if you want them, you get to implement them as part of userland servers. There is no kernel in between to say “this is how it is done”. How it is done is a consensus among the userland components with the kernel abandoning any role for telling them how to things beyond providing the IPC used to communicate. With NUSE and FUSE, the kernel is very much going in between userland processes and saying “do things this way”. Microkernels do not have a monopoly on the idea of moving code into userspace. There are terms for other designs that push things into userspace, such as the exokernel, which goes well beyond the microkernel by handling only protection and multiplexing. I think the term library OS has been proposed for what FUSE/NUSE do. It is a style of doing things that turns what were kernel functions into libraries that can either be accessed the old way through system calls redirected to daemons via shims or as libraries in the process address space. This is an extension of monolithic/hybrid kernels, rather than a microkernel. Closely related would be the anykernel concept as demonstrated through rump kernels, which supports the same code being compiled for both in kernel and in userspace uses: https://en.wikipedia.org/wiki/Rump_kernel https://en.wikipedia.org/wiki/Rump_kernel Earlier work in this area can be found in OpenSolaris, where various kernel code were compiled both as userspace libraries and kernel modules. The most famous example is ZFS (it was/is used to make development faster via stochastic testing), but other things like the kernel encryption module received the same treatment.

> Tanenbaum was theoraticaly correct. He was only correct in a world where programmer and cpu time is free and infinite.

by saati 2y ago

> Tanenbaum was theoraticaly correct. He was only correct in a world where programmer and cpu time is free and infinite.

marcosdumay 2y ago

Care to elaborate how working in a microkernel instead of a monolithic one wastes programmer time? Because AFAIK, every single evidence we have points the exact opposite. Also, microkernels only waste CPU time because modern CPUs go to great lengths to punish them, for no comparable gain for monolithic kernels, apparently because that's the design that they always used.

IX-103 2y ago

I understand CPU time, as micro-kernels tend to be less efficient, but why do you include programmer time? My understanding is that it's easier to develop drivers for a micro-kernel. If you look at FUSE (filesystem in user space), and NUSE (network in user space), as well as the work with user-space graphics drivers, you see that developers are able more rapidly implement a working driver and solve more complicated problems in user space than in kernel space. These essentially treat Linux as a micro-kernel, moving driver code out of the kernel.

ryao 2y ago
A microkernel only gives you scheduling, IPC and virtual memory. You and others get to implement everything else on top of that. That means there are no NUSE or FUSE interfaces and if you want them, you get to implement them as part of userland servers. There is no kernel in between to say “this is how it is done”. How it is done is a consensus among the userland components with the kernel abandoning any role for telling them how to things beyond providing the IPC used to communicate. With NUSE and FUSE, the kernel is very much going in between userland processes and saying “do things this way”. Microkernels do not have a monopoly on the idea of moving code into userspace. There are terms for other designs that push things into userspace, such as the exokernel, which goes well beyond the microkernel by handling only protection and multiplexing. I think the term library OS has been proposed for what FUSE/NUSE do. It is a style of doing things that turns what were kernel functions into libraries that can either be accessed the old way through system calls redirected to daemons via shims or as libraries in the process address space. This is an extension of monolithic/hybrid kernels, rather than a microkernel. Closely related would be the anykernel concept as demonstrated through rump kernels, which supports the same code being compiled for both in kernel and in userspace uses: https://en.wikipedia.org/wiki/Rump_kernel https://en.wikipedia.org/wiki/Rump_kernel Earlier work in this area can be found in OpenSolaris, where various kernel code were compiled both as userspace libraries and kernel modules. The most famous example is ZFS (it was/is used to make development faster via stochastic testing), but other things like the kernel encryption module received the same treatment.