Hello, My name is Irina Presa and I am a final year undergraduate student from University Politehnica of Bucharest, Romania, Computer Science and Engineering Department.
After reading the article "Virtual Kernel Peek" [1], I found vkernel architecture quite impressing. I've also noticed the "Make vkernels checkpointable" project on GSOC page and I would be really happy to work on it. I'm a beginner in kernel programming, so I would like to know if you think I might be suitable for this project. This semester in school, I am attending my first kernel architecture course and I find it fascinating. As for further OS knowledge, last year I had a course of system programming (mostly operating systems concepts applied from userland using POSIX or WIN API). I've also followed Assembly and Compilers courses. About this project, after browsing the sources and the mailing list I came to the following conclusions: Basically, the save and restore of segment registers (especially the TLS support) seems to be the most "sensitive" part. I am not very familiar with this subject (besides the theoretical part I've learned in school) and I would like some advices in this direction. From the mailing list I got to this implementation[2]. Apparently, a starting point would be adding another field in the elf core dump (prsavetls_t tls), that keeps the tls info and stores it from each thread bcopy(&lp->lwp_thread->td_tls, tls, sizeof *tls)). I also found this linux patch[3] which might make a good reference since it implements thread saving and restore successfully. Wouldn't be necessary to also load the tls in the Global Descriptor Table? As for the recreation of the vmspaces, I read here[4] that "it should be possible to do without any modification of the real kernel", allowing the vkernel to save the vpagetable information. Is that a valid solution or we will go by the one described in the gsoc page? Of course, using the host kernel's checkpoint facility in order to save the VPAGETABLES offset and map type shouldn't be a problem, but I thought it would be better to isolate the vkernel as much as possible. As for the vkernel's part, I'm guessing that some cpu_vmspace_alloc calls (that will call the corresponding syscall in order to ask host kernel to do the mappings) using the checkpointed offsets should be enough. And for the last part the dump/load of the current state of network and console drivers I browsed the source code and noticed that: For the network drivers I might need to save the interface/address/netmask/bridge(maybe reading them with ioctl calls) and on restore to reopen each interface (netif_open_tap) and reset it's parameters (netif_init_tap) as the methods from init.c do. The console code would do something similar using termios getattr and setattr. I would be glad to know your opinion on the above, and if you can provide me a starting point - some further reading or even some kernel tests that I could try. Best regards, Irina [1]http://www.dragonflybsd.org/docs/developer/VirtualKernelPeek/ [2]http://gitweb.dragonflybsd.org/~sjg/dragonfly.git/commitdiff/e29b6f2d0c961889b55e94ce7ac6aa0e398d7071 [3]http://www.mail-archive.com/[email protected]/msg00994.html [4]http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/13661/match=checkpoint+vkernel
