If my school had decided to teach operating systems using some non-C language because it's "more clear," I can only imagine that my development as a programmer would have been delayed by years.
Sometimes education is about pure theory, and sometimes it's about how people do things out in the world. I think this is a case where the second approach is much more valuable.
Because C is the de-facto standard for writing operating systems.
If you want to write an oh-cool blog piece for general programmer audiences about how OSes work, sure, go ahead and write it in Python (seen that done, and pretty well, in fact).
But if you want to prepare people to be able to work on real operating systems, they need to know how to do it in C.
I think an OS class isn't meant to prepare you for working on the operating system. The vast majority of people that take an OS class aren't going to work on OSs, but they should appreciate how everything works. Using a language optimized for communicating "how everything works" clearly should be a priority!
Yes, and that language is C. C is a very simple language, and it's very clear. If you're writing anything that interfaces directly with the OS, you'll need to know C.
Perhaps because operating systems are still largely written in C and if a student in the class later goes on to work on OS internals not knowing C would be a major handicap.
> Wouldn't you want to choose a more "clear" language
Are you implying that another language would be more clear?
Quite the opposite, C doesn't hide anything from you. When you want to understand what the computer is doing you can tell directly from the C code. Unlike other languages where you need to understand what the language is doing first, and only then can you understand the computer.
There are time where "hiding" the computer is useful, but not here.
C hides cache, SIMD, registers, the stack (no multiple return values for you!), the details of the heap (malloc() either succeeds or fails, and you can't know what it's going to do until you call it), SMP, instruction-level parallelism, and the details of atomicity, all of which are relevant to OS programming.
C is a nice language. Don't pretend it's how the hardware really works.
...and, particularly crucially if you want to work with numbers, it also hides overflow and floating point exception behaviour. Plenty of processors support trapping arithmetic which signals on overflow and underflow, but this is practically unusable in C.
There's a big difference to hiding and simply not knowing about. If you write a kernel you will need to write architecture-specific primitives (and some non-quite-primitive code, since you bring up SMP) to deal with all the categories you mentioned and some more. Regardless of the language. There is no magic language for writing kernels with a fat runtime to hide the gory details.
C is a nice wrapper around assembly. In a few cases, you wish it were a bit better specified to control the actual assembly/ABI binding a bit better. The problem I see is a lack of contract enforcement which makes introducing hard to diagnose bugs really easy. Maybe Rust will fill the gap.
In Ada you just annotate a procedure as being an interrupt handler and it Just Works.
In addition, you can annotate a protected object (essentially, a group of shared procedures protected by an implicit mutex) as being interrupt-safe, and then any access to that object will be automatically protected by the appropriate instructions.
Plus, if you're in a Posix environment, you can use the exact same mechanism for interrupt handling. It's all remarkably elegant.
Alas, like everything Ada, the documentation is opaque in the extreme, but:
Note that at the bottom they're defining a parameterised interrupt handler structure and then instantiating it multiple times on multiple IRQs, each of which is in its own isolation domain...
What language did you have in mind? It has to be suitable for writing an OS, so Java, python and what not are out. The project has been around for more than a decade so the language has to have had a stable v1 release more than 10 years ago. Also the original code you are working with is in C so you will need to translate it. C seems like a perfectly reasonable choice.
Sometimes education is about pure theory, and sometimes it's about how people do things out in the world. I think this is a case where the second approach is much more valuable.