These are notes (well, at the moment scribbles) on how one might go about re-implementing MULTICS. Don't expect completeness, or even rationality.
The basis of essentially all current memory management is to treat memory as a raw block device. When coding fixed-sized segments, this strategy works very well. It's quick and cheap to implement, and (by being simple) is robust.
However, this won't work for SIMTICS. MULTICS supported a variable number of variable-sized segments, for each process. This can't be done, using the existing approach. Something else needs to be done. One possible "something else" is to have a 3-layer memory management system.
This approach would work as follows:
What does this gain us, other than a system that is horribly complicated? Well, by treating segments as files, they -can- be extended, without running into "collision" problems. Logically, you should also be able to do other file operations on those segments, too, such as creating "directories", concatinating files, etc.
This brings us to the security model, as applies to memory management. By using a file system, each segment and each "segment directory" has all the protections the file system has. This means that you don't need to write one MAC/DAC system for disks, another for RAM, and some bizare combination for swap space.
I am reliably informed that there are NO complete PDP-10 emulators that could run MULTICS binaries. In order to have a platform to test against, such an emulator is going to be critical. (Well, unless someone has a PDP-10 with the necessary hardware that they want to get rid of!)
The consequence of this is that the project has one of two choices:
Obviously, the first would allow the project to leverage existing code. However, that is not always the smart thing to do. This will require closer examination, to see how viable each of the options is.
Compilers aren't any easier. There aren't ANY PL/I compilers for Linux or *BSD, and IBM's PL/I doesn't look like it'll be affordable by any mere mortal, soon.
Again, this leaves the project with a range of options:
Lastly, to clear up one point, this project is about creating a MULTICS-type OS, one slice at a time. The initial slice is to get some kind of development environment running. The next is to extend the sphere of that environment, in a way similar to WINE or iBCS, to produce the illusion of a MULTICS-type environment, even though the kernel is still UNIX. The last slice is to then build an actual, independent kernel, using the code developed to that point as a basis. This kernel would be MULTICS-compliant, in that even complex MULTICS code should run, but may contain many additional capabilities, as time, skill and resources permit.