MH> Perhaps instead of mimicking the kernel data structure in the MH> checkpoint image and then restoring that kernel structure during MH> restart we could create a set of semops to write in the checkpoint MH> image and then perform them during restart. By effectively calling MH> sys_semop during restart we would ensure that we're doing the MH> proper security checks, make the checkpoint image more portable MH> (since the semop interface can't change), and greatly reduce the MH> probability that c/r of the semaphores and their undo lists will MH> bitrot (IOW make maintenance easy for everyone). I actually started thinking down that road at one point. However, the way you get something into the undo list is you take action on a semaphore, specifying that it should be undone later. Unless we add a semop to allow you to arbitrarily adjust the undo list (bad idea, IMHO), using the semop interface would require us to modify the actual semaphore. We could potentially try to replay the semops that led to the semaphore's value at checkpoint, but that seems more likely to break to me. -- Dan Smith IBM Linux Technology Center email: danms@xxxxxxxxxx _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
