3 ms·

Somewhat off topic from the main thread of the article, but I have always wondered about the multiple privilege levels. What's the expected/intended use for the

Somewhat off topic from the main thread of the article, but I have always wondered about the multiple privilege levels. What's the expected/intended use for them? The only thing I think of is separating out hardware drivers (assuming ring 1 can still directly read/write I/O ports or memory addresses mapped to hardware) so they can't crash the kernel should the drivers or hardware turn out to be faulty. But I don't think I've ever heard of such a design being used in practice. It seems everyone throws their driver code into ring 0 with the rest of the kernel, and if the driver or hardware faults and takes the kernel with it, too bad, so sad. Ground R̅E̅S̅E̅T̅ and start over. What I find myself wondering is why? It seems like a good idea on paper, at least. Is it just a hangover from other CPU architectures that only had privileged/unprivileged modes, and programmers just ended up sticking with what they were already familiar and comfortable with? Was there some painful gotcha about multiple privilege modes that made them impractical to use, like the time overhead of switching privilege levels made it impossible to meet some hardware deadline? Silicon-level bugs? Something else?

monocasa 5y ago
It works with the call gates. You could have a sort of nested microkernel idea if it wasn't such a mess with each ring able to include the lower privileged ring's address spaces. And not just a free for all, but the kernel really is just the control plane, but can set up all sorts of per process descriptor tables (the LDTs). So you'd have a tiny kernel at ring 0 which could R/W everything but wasn't responsible for much. Under that you'd have drivers at ring 1 that can't see the kernel, but can R/W user code at rings 2 and 3. Under that you'd have system daemons at ring 2 that can R/W regular programs but not drivers or the kernel. And then under that you had regular processes at ring 0 that have generally the same semantics as today's processes. Each process of any ring can export a syscall like table through the call gates, and so user code could directly invoke drivers or daemons without going throught the kernel at all. Basically IPC with about the same overhead as a C++ virtual method call. So what happened? The exact underlying semantics didn't exactly match many OSs anyone wanted to build (particularly OSs that anyone cared about in the late 80s early 90s). And you can enforce similar semantics all in software with the exception of the cheap IPC anyway.
dmitrygr 5y ago
I think OS/2 used every feature x86 had, including call gates and at least 3 privilege levels (0, 2, 3). That is why OS/2 is such a good test for any aspiring x86 emulator developer.
- kiwidrew 5y ago
  I think OS/2 and XENIX were the only two operating systems that ever used 80286 protected mode. I'm not surprised that OS/2 makes a good test case for emulators!
  - userbinator 5y ago
    Windows/286 did too, and so does Windows 3.x in "standard mode".

monocasa 5y ago

It works with the call gates. You could have a sort of nested microkernel idea if it wasn't such a mess with each ring able to include the lower privileged ring's address spaces. And not just a free for all, but the kernel really is just the control plane, but can set up all sorts of per process descriptor tables (the LDTs). So you'd have a tiny kernel at ring 0 which could R/W everything but wasn't responsible for much. Under that you'd have drivers at ring 1 that can't see the kernel, but can R/W user code at rings 2 and 3. Under that you'd have system daemons at ring 2 that can R/W regular programs but not drivers or the kernel. And then under that you had regular processes at ring 0 that have generally the same semantics as today's processes. Each process of any ring can export a syscall like table through the call gates, and so user code could directly invoke drivers or daemons without going throught the kernel at all. Basically IPC with about the same overhead as a C++ virtual method call. So what happened? The exact underlying semantics didn't exactly match many OSs anyone wanted to build (particularly OSs that anyone cared about in the late 80s early 90s). And you can enforce similar semantics all in software with the exception of the cheap IPC anyway.

dmitrygr 5y ago

I think OS/2 used every feature x86 had, including call gates and at least 3 privilege levels (0, 2, 3). That is why OS/2 is such a good test for any aspiring x86 emulator developer.

kiwidrew 5y ago
I think OS/2 and XENIX were the only two operating systems that ever used 80286 protected mode. I'm not surprised that OS/2 makes a good test case for emulators!
- userbinator 5y ago
  Windows/286 did too, and so does Windows 3.x in "standard mode".