anon2 (anon.delete@this.anon.com) on March 15, 2021 1:58 am wrote:
> Anon (no.delete@this.spam.com) on March 14, 2021 11:49 pm wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on March 14, 2021 4:58 pm wrote:
> > > That kind of thing could be useful for a microkernel (not that I believe in the
> > > concept - I continue to be of the opinion that microkernel proponents are overplaying the advantages,
> > > and underplaying the very real issues with communication and sharing).
> >
> > In several places I saw Linux being classified as "microkernel", I never touhgt
> > this classification have any relevance, but now I read you bashing the concept.
> >
> > So, is Linux a microkernel after all?
>
> No. It has taken some concepts and applied them where they are are a good fit
> (e.g., to implement userspace device drivers for certain classes of device).
>
> > What is the true concept of microkernel?
> >
>
> Traditionally it is a minimal kernel that supports only thread scheduling, low level interrupt handling,
> IPC, and perhaps low level virtual memory management. The rest of the kernel services are built with threads
> (which may or may not be in different address spaces and privilege modes) on top of that base.
>
> It sounds like such a nice clean idea that even experienced computer scientists
> and engineers throw away careers trying to make it work like a monolithic kernel.
> The reality is not all problems can be decomposed into "clean, simple".
>
> But when you step back and think about things a bit more generally and not just myopically at the kernel,
> it's much less of a surprise that it doesn't work well -- would anybody think a "microuserspace" is
> a good idea? glibc broken up into dozens of services running as threads, every application in the system
> making IPC requests to the memory allocator server for malloc and free, to the string server for memcpy
> or strlen, to the file server for fopen/fclose, etc.? No, when you put it that way it's easy to see
> it's not actually all that nice and clean at all. Particularly if you want to get non-trivial performance
> or scalability from it. There is certainly no fundamental nicety to it.

I see you never mentioned security so I guess that's not of interest to you. If you really want performance you should get rid of the user/supervisor distinction as well. If you have megabytes in the system and it is being constantly improved it doesn't really give stong security, just a constantlty rolling protection via updates against script kiddies.