> > Once you start implementing persistence by degrees you run into a > > whole bunch of edge cases where it's just easier to implement > > system-wide persistence anyway. That's been my experience, in any > > case. > > I guess so. Have you been working on > persistence/checkpointing mechanisms? >
Yes. Using the spoon microkernel as a starting place (http://www.djm.co.za/spoon/) I've been experimenting with capabilities and persistence. I was talking with the kernel's author about several things we'd like to implement, one of them being a more generic IPC mechansism that will support map, grant, and copy for all IPC. There's also a very fast copy operation that simply transfers 6 dwords to a vector in the receiving thread. All operations are asynchronous. However, we both feel that we would like to make some changes to the API to make some things more secure. For example, instead of having global thread and process ids, all ids will be local and a translation table will exist in the kernel's thread structure to map those to the kernel's global process/thread id. This should essentially confine all communication between executable objects, and it also provides a way to check if a given thread can communicate with any other given thread, or any thread at all. I'm still thinking about the introduction problem (how do two threads get a hold of each other to perform some communication without a global nameserver.) Regarding persistence, I've been working on a streaming protocol that would let the kernel checkpoint a process (and all of it's threads) on the fly. At first the idea was to just stream binary data through IPC's to a trusted user-land process that treats the whole disk like a circular transaction log. The problem with that involves performance: copying data, and formatting and reformatting data on the inbound/outbound. The plus was going to be that some kernel structures could be persisted (transacted) while others weren't, hopefully allowing for a finer-grained transactions that didn't require stopping the world. Or the whole process, at a minimum. The problem isn't that an incremental and partial persistence mechanism is hard to make, it's that the recovery mechanism is hard to make. Each aspect has dependencies that must be checkpointed before it is in order to ensure a stable recovery image. Once you walk the dependency chain and checkpoint each of those pieces, you might as well have checkpointed the whole thing. My other idea regarding that is to simply have a transaction log of the *operations* performed. So that when a thread is deleted you first note the thread deletion in the log. Once that completes, you delete the thread. A similar operation would happen for all significant operations, but the only actual data that would be retained would be memory contents. The difference is like the difference between the old .3ds format that stored the 3d-model, and the new .max format that stores the commands to rebuild the model. I'm not convinced that this is performant. -={C}=- _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
