[kragen]

a lot of people agree with you, which is why minix exists (though their source control system just fell offline this year), but none of windows nt, linux, os/360, and even really macos/ios are microkernel designs. sel4 and the other l4 variants are, and so is qnx, and linuxcnc runs linux under a microkernel, and xen is kind of a microkernel if you look at it funny, so we're definitely seeing significant mainstream use of microkernels, but it's not clear that that 50-year-old design is actually obsolete the way the pdp-11, the cray-1, and the system/370 are

[js8]

Actually, z/OS (descendant of System/370) is more microkernel than Linux is. But the problem with microkernels is similar to the problem with microservices - you have to make the executive decisions somewhere, and that unfortunately ends up being the bulk of "business logic" that the OS does.

In theory, I like the concept of functional core, imperative shell - the imperative shell provides various functions as a kind of APIs, and the functional core handles all the business logic that involves the connections between the APIs. (It's also sometimes called hexagonal architecture.)

However, it is questionable whether it actually reduces complexity; I daresay it doesn't. Every interaction of different shell APIs (or even every interaction that serves a certain purpose) needs a controller in the core that makes decisions and mediates this interaction.

So when you split it up, you end up with more bureaucracy (something needs to call these APIs in between all the services) which brings additional overhead, but it's not clear whether the system as a whole has actually become easier to understand. There might also be some benefit in terms of testability, but it's also unclear if it is all that helpful because most of the bugs will then move to the functional core making wrong decisions.

[kragen]

i admit to not being very familiar with the current version of os/360; can you elaborate?

btw, when you say 'z/OS (descendant of System/370)', i think you are confusing hardware and software; system/370 was the hardware (obsolete), os/360 the software (sadly, not obsolete; later renamed os/370, mvs, and z/os in a series of increasingly desperate attempts to escape its reputation)

generally the functional/imperative contrast centers on mutability: imperative style uses mutability, and functional style doesn't. is that what you mean? i'm not sure a functional core in the sense of 'mutation-free core' is a reasonable way to build a computer operating system, because limiting resource consumption and handling failures reliably are two central concerns for operating systems, and typically immutability makes them much more difficult. immutability does have a lot of uses in modern operating systems, but at least on current hardware, it makes more sense to me to build it as an functional shell around a mutable core than the other way around

(the other aspect of the functional/imperative axis has to do with constructing new functions at runtime, passing them as arguments to subroutines, and returning them from subroutines: you do these things in functional programming, but not in imperative programming. i am at a loss how this could relate to what you're talking about at all.)

it's not clear to me what https://web.archive.org/web/20070403130947/http://alistair.c... has to do with functional-core/imperative-shell or for that matter with operating system kernels. can you elaborate?

for the most part operating systems design is an exercise in delegating as much as possible of those 'executive decisions' to userspace. 'mechanism, not policy' is the mantra for kernels and for system software in general, including things like device drivers and window servers. that way, you can use different policies in different parts of the system and change them over time without destabilizing the system. i feel like microkernels are generally better at this than monolithic kernels, and sel4 in particular takes this to the extreme

[js8]

Ah, sorry for the inaccuracies. I mean MVS as a predecessor of z/OS, of course.

What I mean by functional core/imperative shell is similar to what you mean by (the "kernel" is the "imperative shell" and the "userspace" is the "functional core"):

"for the most part operating systems design is an exercise in delegating as much as possible of those 'executive decisions' to userspace. 'mechanism, not policy' is the mantra for kernels and for system software in general, including things like device drivers and window servers"

And z/OS does that a lot, much more than Linux. On a typical z/OS, many of the functions that would be normally running inside Linux kernel are running in a separate address spaces, with limited authority.

But the intractable problem IMHO is, to decide the policy, you still need the authority to do so (you need to be able to invoke the commands to the kernel), so you can still wreak havoc in the system.

[kragen]

like what?

[js8]

For example, on z/OS, the whole disk storage subsystem (SMS, but there is more) is separate from the MVS (kernel). Security is also externalized in RACF server (in fact there are alternate products from non-IBM vendors). You can run multiple TCP/IP stacks, which are also running in their own address spaces. Sysplex serialization has its own address space.

All the address spaces involved in the operating system are coordinated through SVC or PC routines, which are like system calls, and scheduling of SRBs, which are kinda like kernel threads. I am not sure (although I am not aware of latest developments) if in Linux one can define a custom system call, like you can on z/OS. Or if you can schedule your own kernel thread from user space.

You seem to know about MVS, yet we probably disagree on whether it is to be called a microkernel or not. I am not an OS expert, and I never did kernel-level programming for Linux or z/OS. But I did read Lister's Fundamentals of Operating Systems long time ago, and that book is somewhat based on what MVS (the actual kernel of z/OS) does. It was written before the whole microkernel debate, which AFAICT might be just an artifact of enormous variety and complexity of x86 hardware.

So I would like to hear, in your opinion, what should have been different in MVS (or z/OS) for you to consider it a microkernel?

[kragen]

i don't know enough about it to have an opinion. thanks!

[shawn_w]

>minix exists (though their source control system just fell offline this year),

https://git.minix3.org/index.cgi seems online?

[kragen]

this started failing, i think, last week:

    : ~; git clone git://git.minix3.org/minix.git 
    Cloning into 'minix'...
    fatal: Could not read from remote repository.

    Please make sure you have the correct access rights
    and the repository exists.

[pjmlp]

While Windows and macOS aren't pure microkernels, they certainly are much more in architecture than pure UNIX clones will ever be.