From two books’ review
Daniel Bovet and Marco Cesati. Understanding the Linux Kernel (2nd Edition or newer):
Note: this book has some tendency to function as a play-by-play of
what happens inside Linux (on an x86) as opposed to a design book.
You may find the BSD book or the Love book more design-oriented.Robert Love. Linux Kernel Development:
We received some complaints about the 2003 edition containing too much
play-by-play material, but the 2005 edition has received favorable student reviews. You may find that the BSD book provides more
historical and design perspective. You should also know that
people familiar with other operating systems may dispute some
historical descriptions and claims of architectural novelty.
What differences are between “play-by-play”, design and implementation of an OS?
For example, how do they differ in terms of what they consider and what they want to accomplish?
What do “play-by-play”, design and implementation of an OS mean? I don’t know what “play-by-play” mean here. Does “design” mean creating a logical/abstract model, and does implementation mean implementing the logical/abastract model using hardware and programming?
I am always confused by the words “design” and “implementation” used in the tiles of books on OS, database, programming languages. There are also other books in the areas without the words. In general, what do such titles imply about the books’ topics?
Are there other aspects about operating systems, besides design and implementation?
Thanks.
1
It’s a sports analogy. Play-by-play is what you learn from a commentator while watching a game. A “design” approach would be more akin to reading that game’s rule book.
For a kernel book, a play-by-play example might start with an open call on a file, and trace that through the filesystem code, through the block device code, through the usb subsystem, through a device driver for a specific thumb drive chip, through primitives like kmalloc, and back on out to user space.
A lot of people learn well that way, but it only gives you a deep understanding of the specific use cases it covers. A design approach would give you a broader understanding of how everything fits together at the high levels. It’s like the difference between a suite of unit tests and an architecture document.