They are interesting reads (and practices) for anyone with a passion in CS in general and especially the more math like side of it.
Though IMO, from a pure engineering/project management aspect, there's not much value unless you are working on the OS as part of a big team (way more than 20,30 people) or the OS is already very very advanced that you can afford to specialize and do R&D in a small sub area.
A crude example, how do you implement spin lock in your kernel for x86?
Perhaps some 'original' flavor of the test test and set as appeared in the x86 manual, perhaps something more advanced.
And you may know that 30 years ago there's a paper introducing the MSC lock, which beats out 4 or 5 other flavors (variants) in terms of latency and system bus load in contentious periods where up to 80 CPUs compete for the same spin lock while maintaining FIFO.
More than 25 years later, after much deliberation of structure sizes, etc. and performance upsides, a variant of MSC lock is merged into the Linux kernel.
Now you have a few choices:
A. continue to use what you have, which will serve you well for a long time (at least Linux managed just fine well into 2010s without converting to MSC lock)
B. copy Linux, implement MSC lock (it is literally just a few lines of code), blindly (but correctly) believing in its 'proven correctness and performance'
C. come up with MSC lock yourself, or at least look at the answer and then mathematically prove its properties like correctness, latency and FIFO given the properties of primitives like atomic compare and exchange
Plunging into this set of books as a practical guide for OS dev is like making choice C for each design decision as small as 'how do you implement spin lock in your kernel for x86' . Good luck and have fun
