Hey, James. Nice to see you w/ parallels hat on. On Thu, Jul 28, 2011 at 08:37:59AM +0000, James Bottomley wrote: > So, this is actually a good example of why we don't want this > specifically bound to C/R in the kernel. I think an individual network > socket can be checkpointed and restored separately specifically by > exporting some of its internal state (basically the current sequence > number and some of the window state). I actually think network socket would be a pretty well behaving candidate for userland CR. Its behavior and interaction are strictly defined. The thing is designed to talk to other machines after all so we basically already have well documented and enforced mechanism to coerce it. We need some bits and pieces but I'm expecting kernel side of it to be very small. > The benefit to us of finding what this state is and making it available > is not only that we can now save and restore the socket as part of the > checkpoint, its that the High Availability people can use this feature > for individual sockets to build fault tolerant network service failover > on top of. Thus by making the feature granular and available to > userspace, we've expanded the number of use cases (and hence the amount > of testing) we get for the feature. Yeah, exactly, and that in turn makes it easy to push the feature into the kernel. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
