On 07/23/2011 12:37 PM, Tejun Heo wrote: > Hello, > > On Sat, Jul 23, 2011 at 12:11:37PM +0400, Pavel Emelyanov wrote: >> On 07/21/2011 10:44 AM, Tejun Heo wrote: >>> Most of information dumped here is already available >>> through /proc and ptrace and we can add the missing pieces like the >>> suggested proc vma fds. >> >> Let's start with the simplest things. Can you suggest the best (from you pov) >> way for dumping all the registers, tls and the anonymous pages through the >> existing interfaces? > > Just use ptrace. Seizing all threads in a process, gather file and > memory map info from /proc, inject a parasite to dump memory pages and > do whatever else. There's nothing special about TLS, fs/gs base is > already included in ptrace register dump in x86_64. Dunno how it's > handled in 32bit but if it's not available exporting it isn't a big > deal. Rebuilding the process image from the captured information > shouldn't be too hard. You're talking about your recent set for ptrace? Can you propose a quick scratch of how you propose to dump and restore registers and memory with this? > There is simply is no need to put CR into kernel at all. I don't want to! I propose to use small set of APIs for it and the execve handler is just the way to replace VM+regs of a task with another set. > Just add the > missing pieces to export the necessary information and missing APIs > which are required to restore it (e.g. setting TID like you did in > this patchset). Approaching it that way would make things useful for > other use cases && is highly more likely to get merged. There doesn't > even need to be one big merge day. You can just improve things > piecewise until it works. Totally agree. > Thanks. > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers