Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
new device model #26
@dtribble and I walked through a new device model this morning, and I think it makes enough sense to implement eventually:
For the inbound-comms-vat use case, we were thinking that devices are allowed to put deliveries onto a special queue that gets handled before the regular run-queue.
The bootstrap vat would get all configured devices as arguments of the iniital
The API of a Vat is still pure data, so I don't think this will make migration any more difficult. And it removes the current raw-JS-object endowment pattern, which should make it easier. It means devices are only slightly more powerful than regular references: the one thing they add is synchronous invocation.
For the latter, we currently record all syscalls (and their return results) in the transcript. Specifically, we record all kernel-to-userspace
When we restore a vat from the saved state, we replay the
By routing userspace-to-device access through the syscall API, we get this same deterministic replay for free. The vat won't be interacting with the real device during replay, but it will get the same return values that it got the first time around. Any since the device-to-userspace pathway goes through the run-queue (albeit a higher-priority one that should always be empty in a checkpoint), all those messages are effectively captured in the vat's transcript.
Of course, the device itself must be restored to the same state too. Devices, like the kernel, will add their own state into the machine-wide state vector, right next to the vat transcripts. I think that will be sufficient, as long as we have some interlocks to prevent the device from e.g. submitting any vat messages before we've replayed all the vat transcripts.
I haven't thought so much about turn aborts. I expect this is the spot where devices must promise to buffer their effects until a checkpoint has been taken.
referenced this issue
May 1, 2019