Love4Boobies wrote:There are a few things I didn't like about your proposal. First, there seem to be some inaccuracies (e.g., processes and threads are not scheduling primitives, deadlocks are not synchronization issues). Secondly, the categorization is a bit off (e.g., threads are presented where processes are but thread states are discussed elsewhere).
Of course, despite the formatting, this list was not meant to be a final tree structure, but just a broad list of keywords (and so the categories were not meant to be accurate). This definitely still needs some sorting and proper categorization, it's just a first draft.
Thirdly, and this is my main complaint, I don't really like all this inconsistent spreading around of articles: We keep theory separate from design but mush design and implementation together.
In this first draft, I used "design" and "implementation" synonymously in the sense that "it is a design decision, how I implement my memory manager, i.e., using a flat heap or slab allocator". But of course, one can have a more fine-grained separation, if that makes sense (different designs of memory allocators, vs. how they are implemented in some given programming paradigm). These terms are relative, after all - there is a whole hierarchy of "implementations", from the algorithm down to the bare machine instructions.
I haven't given the organization too much thought so don't consider this a blueprint. For instance, although books on OS theory don't really treat them this way, to my mind, it makes a lot more sense to put Threads under Processes, since to former are a type of resource and the latter are ultimately resource containers with privileges, relationships, etc. Textbooks typically discuss process states (by this I mean Ready, Running, Blocked, and Terminated) and then later say "threads are pretty much like that, too". How about making these a characteristic of threads only since processes can be single-threaded? I think there are a lot of pedagogical opportunities like that.
I think it should ideally be somewhere between a good pedagogical work and a practitioners guide. It might be neat to have a wiki which could also be used as an actual course material, but I don't think that this is the intention or use case of most of its users. So one goal of a good wiki organization should also be how to easily and quickly find the article you need when you are facing a particular task or problem in the course of writing your OS.
PS: I was also amused to see Turing machines mentioned under architectures. Surely we're not going to write a crash course into computability theory so such theoretical models are of little value to this wiki.
Again, this was just an example for some topic, to give another possible viewpoint on a computer from the theoretical side, besides von Neumann architectures and finite state machines, to name just two other examples. It might help at some point to view a computer as one or the other.
