First, the object has to have been designed with upgrade in mind, so that you can transfer data from the old object to the new. Given that, here's how the upgrade occurs:
The upgrader stuns the old object by waiting until the old object is idle and demanding a fault capability to it. At this point, the old object is frozen and cannot be invoked by anyone else.
The upgrader now clones the process nodes of the old object's process. In effect, we have just copied the old object into a new process.
The upgrader now installs into the old process a new address space: the address space for the new object. It then sets the old process registers to the appropriate startup values to give the new object a chance to initialize itself. It also places a capability to the old object into a well-defined register in what is now the new object's process. Note that we've now effectively done a complete brain transplant on the original process. All holders of the old object still have capabilities to this process, which is now obeying new code.
The upgrader now lets the transplanted process start running. During initialization, the new object uses its capability to the old object to transfer any necessary data from the old object and then tells the old object to destroy itself.
Finally, the new object returns to the null capability, becoming available for new invocations.
It all sounds much more complicated than it is. Most of this can be built in a library.
Actually, it was always planned that this project would be open sourced. I made that commitment to Norm Hardy in 1991. If you looked at the copyright assignments my students gave for their work, you'll find that they explicitly mentioned that this work might be open sourced.
The original research release occurred before EROS was ready for other people to work on it. A lot of people were wanting to look at the code, and I wanted to make it possible without getting flooded by reaction. The result was a lot of flack from bratty college kids claiming that they were entitled to EROS for free because they said so. This was taking a lot of my time, and led me to put up the $$$ figure (which is accurate, by the way) to get them to go away.
The second license (a modified MPL) was open source, with the qualifier that I had reserved rights to everything. The purpose of this was to get a few early people to help check things out without being overwhelmed while I finished my dissertation. Also, I wanted to figure out how to deal with the security branding issue.
I am now done with my dissertation, and the branding issue has been resolved, thus GPL.
Indeed the FAQ hasn't been updated, which is an error on my part in cutting the GPL release. It should be fixed very shortly.
First, memory is a cache, not all of the system. Thus, there is no limitation. Current EROS systems are happily running with 10s of gigabytes of storage, and the object space design in the research version will support very large stores indeed: 70,368,744,177,664 Gbytes. I believe this is somewhat larger than the total world output of disk storage since the start of the computer industry.
Just so you know, the 2Gbyte limit is a Linux limit rather than an x86 limit. In EROS, every process gets up to 3Gbytes of virtual address space, and this could be raised to 3.5Gbytes without a lot of work. The 3Gbyte space is potentially a window onto a much larger space.
Card state and external connections are not persistent. In the case of your example, it is the responsibility of the display manager to be able to recreate the state of the display when the system restarts.
There is a designed means for applications to pre-initiate the fault-in of data. It's not yet implemented, but it's a trivial change to the existing capability load/store logic. Think of it as a load instruction that returns no result.
There is also a designed mechanism for keeping objects in memory. Regrettably also not yet implemented. As I said in an earlier response, the real-time features of EROS are not really there yet.
The current EROS system is not real time, though the real time design is complete and could easily be implemented. The kernel currently has a real time scheduler, but the disk system needs to be enhanced a bit to really do the job well, and a model for exemption from checkpoint is probably called for.
This is a case of drift between the web site and what has so far been completed.
More generally, you don't even need root authority in UNIX to kill your own processes, so the question was a bit confused to begin with.
In EROS, the model is that you provide the storage and the CPU time that your programs execute with. While you can't examine the storage these programs allocate without their permission, you can shoot the storage allocator from which they were obtained, which reclaims all of the storage (including the processes).
It is certainly possible for erroneous programs to "forget" authorities that they need to have to function. The critical system software is carefully written to avoid doing this, and it's the sort of problem that is unlikely to spread beyond the scope of a single, ailing program.
See my answer about killing programs, as that is also relevant.
While DARPA did indeed fund some of the work we did, all of that funding was related to active networking research rather than the secure operating system per se. Several years later someone at CIA expressed interest in the system as a way to solve some internal concerns they have, but it never went anywhere.
I think my observation here is that conspiracy theories are usually oversubscribed.
Slashdot Mirror
The upgrader stuns the old object by waiting until the old object is idle and demanding a fault capability to it. At this point, the old object is frozen and cannot be invoked by anyone else.
The upgrader now clones the process nodes of the old object's process. In effect, we have just copied the old object into a new process.
The upgrader now installs into the old process a new address space: the address space for the new object. It then sets the old process registers to the appropriate startup values to give the new object a chance to initialize itself. It also places a capability to the old object into a well-defined register in what is now the new object's process. Note that we've now effectively done a complete brain transplant on the original process. All holders of the old object still have capabilities to this process, which is now obeying new code.
The upgrader now lets the transplanted process start running. During initialization, the new object uses its capability to the old object to transfer any necessary data from the old object and then tells the old object to destroy itself.
Finally, the new object returns to the null capability, becoming available for new invocations.
It all sounds much more complicated than it is. Most of this can be built in a library.
The original research release occurred before EROS was ready for other people to work on it. A lot of people were wanting to look at the code, and I wanted to make it possible without getting flooded by reaction. The result was a lot of flack from bratty college kids claiming that they were entitled to EROS for free because they said so. This was taking a lot of my time, and led me to put up the $$$ figure (which is accurate, by the way) to get them to go away.
The second license (a modified MPL) was open source, with the qualifier that I had reserved rights to everything. The purpose of this was to get a few early people to help check things out without being overwhelmed while I finished my dissertation. Also, I wanted to figure out how to deal with the security branding issue.
I am now done with my dissertation, and the branding issue has been resolved, thus GPL.
Indeed the FAQ hasn't been updated, which is an error on my part in cutting the GPL release. It should be fixed very shortly.
Just so you know, the 2Gbyte limit is a Linux limit rather than an x86 limit. In EROS, every process gets up to 3Gbytes of virtual address space, and this could be raised to 3.5Gbytes without a lot of work. The 3Gbyte space is potentially a window onto a much larger space.
Card state and external connections are not persistent. In the case of your example, it is the responsibility of the display manager to be able to recreate the state of the display when the system restarts.
There is also a designed mechanism for keeping objects in memory. Regrettably also not yet implemented. As I said in an earlier response, the real-time features of EROS are not really there yet.
This is a case of drift between the web site and what has so far been completed.
More generally, you don't even need root authority in UNIX to kill your own processes, so the question was a bit confused to begin with.
In EROS, the model is that you provide the storage and the CPU time that your programs execute with. While you can't examine the storage these programs allocate without their permission, you can shoot the storage allocator from which they were obtained, which reclaims all of the storage (including the processes).
See my answer about killing programs, as that is also relevant.
I think my observation here is that conspiracy theories are usually oversubscribed.