OSDev.org

I'm considering writing a design document before continuing with my OS. Rather than just having a rough idea in my head, and then complete one thing and think "What should I work on next?" without any real clear direction, I am going to write a design document that covers everything from the lowest level:
- Booting
- Memory Management (layout/where it'll be allocated/how/DMA)
- Drivers (APIs/layout/how they load/etc)
- Process Management (permissions, sharing time slices, etc)
- VFS
- IPC
- User Managment
- etc

To the highest level including exact UI design of each tool.

I think writing a design document and having clear defined goals will help because then you know what you are aiming for and a path on how to get there. It'll also help to minimize feature creep, code bloating, and re-writing large parts of your code to support extra features.

I will call the design document "v1" and I'll stick to the design document to the word. My OS reaches version 1 when it is a stable implementation of the design document. Once I have reached version 1 I will take a break and later write a design document labeled "v2", etc.

Once I reach version 1 I can still provide updates and add extra features not found in the design document v1 before writing design document v2. These will mostly be minor updates, and for this I'll branch the source code, one being the vanilla version 1 that I won't change and the other being a copy of version 1 that I will change. Once I have finished v2 of the design document, I will base my v2 code base off the vanilla code of v1, to reduce code bloat and to eliminate the sticky-taped-together ideas from my other branch (although most of the ideas in these updates will probably have found their way into design document v2).

Im interested in the versioning and design systems other people are using. Who else has written a design document?

MessiahAndrw wrote:Im interested in the versioning and design systems other people are using. Who else has written a design document?

I am, currently. But not bottom-up, like your list, but top-down. The low-level stuff is really not that interesting, it's the same for each OS. What's import is the higher level building blocks. Start with questions like "do I want a micro kernel or a monolithic one (or something in between)", "do I want multi-tasking, and if so, what kind (do I have processes, threads, something else?)", "how or processes/threads going to communicate (IPC)", "how modular is my OS going to be", "do I want to follow some standards (e.g. POSIX)", "do I want a distributed OS, or a desktop OS or a server OS or an embedded OS or something else?", "is my OS file based, object based, something else?" and so on and so forth. Decide what you really do not want (e.g. a Linux clone), and what you really do want (e.g. plug & play modules).

But in general, it's good to write down what you aim for, it prevents a lot of drifting and feature creep, so I applaud your decission.


JAL

Also, writing a design document makes your brain work through problems harder, and so you get fewer big mistakes. However, I wouldn't recommend you stick to the word of the design document. Allow yourself to make changes to the document, otherwise your design will go stale. You'll find things that can be done better, and these should be done better. And you design document should reflect that.

I've been writing design documents for a few of my larger projects (including my operating system project), and I can say that it is absolutely great. I recommend though that instead of a single document, you have a collection of documents, just like what you would do with source code. It makes it easier to maintain, and you can collect your 'idea modules' to match your code modules.

I have Subversion installed on my server, but I've never bothered to use it. Religious use of backup scripts and tarballs has been all I've needed. That said, I can imagine proper version control being very useful on projects with more than one developer.

You have inspired me - I am now writing a design document to give my OS some sense of direction.

Cheers,
Adam

Now that I have a clear and well thought out design, I have some sense of where I am in terms of progression.

I currently have 13 items on my to-do list before I reach v0.1. To put "13 items" into perspective, that's about 75% away from when I began my OS.

2 years working on my OS and I'm only about to reach version 0.1
That's including porting to C, porting to C++, rewriting my VESA driver twice, switching to a higher-half kernel, among a few other things. And a lot of mindless coding without any real sense of direction.

Now the my OS's future looks a lot brighter now that I have a stable vision/design.

The first release will contain things like FAT12 support, loading/unloading ELF binaries, VESA driver, basic window management, preemptive multitasking, multiple threads per process, and a kernel level message/event system, and a few simple test programs.