List of design considerations

[0Scoder]

Hi,
I have been thinking about my OS design recently and realising the impossible amount of things you have to take into consideration and plan for in order to have a good design. Now, would anybody know of (or be interested in making) a detailed checklist of everything you have to think of to form a comprehensive OS design? I don't remember seeing anything like this on the mega-tokyo FAQ, but something like it would be nice to have. By details I mean things like whether your IPC can do mutal exclusion properly on a multiprocessor system, and what things you can/can't do if you want to be 64 bit compatible (I know the fact the intel standard doesn't allow segmented memory protection may catch people out!).

Thanks,
OScoder

[smiddy]

I think this is a great idea. I fear the permutations of a list can drive design requirements. Since I assume you're wanting to brainstorm on the highest level design decisions and then from those drive down lower level requirements, and this is based on the OS kernel, nothing more, correct? Because I think you can get into application environments where the design drivers might change the type of system entirely.

Where do we start?

[0Scoder]

I was thinking in terms of the core of the OS - you know, IPC mechanism, etc. Mostly in terms of what inexperienced osdevers ought to think about early to avoid getting caught out later, or things they might put into their design that would actually be unworkable!

Any chance of people posting things that might go on a list in this thread?

[Combuster]

Any chance of people posting things that might go on a list in this thread?

I'll post some random things. Wether its useful for any list is up to you

If one has some senses and cares to read the manuals some 10 times it wouldnt be too hard to check things for consistency.

Basically, every design failure i came across myself was due to not knowing the architecture details. If you're able to form some pseudocode about how things should be done on the hardware level you basically have run a sanity check on your design.

Also, watch out for chicken-and-egg problems. (or bootstrap problem or whatever you want to call it) Example: a few months ago my kernel could be locked up if you tried allocating memory when all allocated PDs were full: it would need memory to create a new PD, but it then memory needs to be mapped in order to write the PD, since all PDs were full, you'd need a new PD etc etc... I eventually fixed it by having a reserved area where i could temporarily map a page of physical memory.
But then again, not everybody builds an exokernel and likes to have the user apps to be able to choose the location where in virtual memory to map paging structures...

As for the list itself: it would be useful for newbs and experienced programmers alike. On the other hand its not really useful when some people rather fill in the text box here than on google ...