anon2 (anon.delete@this.anon.com) on March 15, 2021 8:31 pm wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on March 15, 2021 11:51 am wrote:
> > anon2 (anon.delete@this.anon.com) on March 15, 2021 4:59 am wrote:
> > > dmcq (dmcq.delete@this.fano.co.uk) on March 15, 2021 4:06 am wrote:
> > > > 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.
> > >
> > > Non sequitur.
> >
> > In the computer industry you have to make your priorities clear.
>
> You blame me because you made a false assertion due to invalid assumption
> that was not supported by anything I wrote or implied? lol
>
> > Any you leave out are maybe 'would
> > be nice'. You have put in performance and scalability and clean code. The first three of the priorities
> > are as much as one can expect from a project and those already will require trade offs.
>
> I can't decipher your blathering, but I'm afraid you are wrong. Try being constructive
> next time rather than coming straight out the gate with such garbage accusation.
>
> >
> > > > If you really
> > > > want performance you should get rid of the user/supervisor distinction as well.
> > >
> > > Ironic. In fact it is microkernels that tend to get rid of those "clean" layerings and
> > > abstractions from their ivory tower architecture vision when the rubber hits the road
> > > and they find performance is so terrible they need to start mashing together their academically
> > > (alleged) beautiful design of privilege and memory protection modes.
> >
> > Perhaps you can give an illustration of what you mean?
>
> Kind of like how Apple used a microkernel and it sucked so they had to start putting
> device drivers in the kernel and then half of a BSD kernel in their kernel space so
> now device drivers, filesystems, network stack are all running in the kernel.
>
> In other words, they really wanted performance sothey got rid of the user/supervisor
> distinction for all their microkernel services of importance.
>
> (And their performance still sucks sadly for them, in no small
> part due to the underlying microkernel foundations)

Apple runs most drivers (more every year) in userspace:
https://developer.apple.com/documentation/driverkit

Evolution towards ever more user-space networking is on-going:
https://devstreaming-cdn.apple.com/videos/wwdc/2017/707h2gkb95cx1l/707/707_advances_in_networking_part_1.pdf

Apple uses XPC (IPC, rather than function calls) as the primary communications mechanism from userspace to any service that has RAS implications:
https://www.objc.io/issues/14-mac/xpc/