![]() | ||||||||||
Messages in this thread |
jeremy@goop.org said: > I suspect Valgrind could use this too at some point. There hasn't > been much discussion about it yet, but I think Valgrind may well move > towards a more complete virtualization in a later round of > development, and isolating the virtual virtual address space from the > Valgrind's real virtual address space would be very useful. (Jeff > suggested the idea of merging Valgrind and UML at some level, which > does raise some interesting possibilities.) Yes, valgrind already has a pseudo-scheduler, a psuedo-threads library, it delivers signals by hand, and it wants to run its client in a separate thread so it can get out of the business of being an LD_PRELOAD shared library. This is all stuff that UML has, that UML does right (/me crosses fingers), and that is usable by Valgrind (and anything else that's interested) with some repackaging of UML as a library. Replacing Valgrind's signal delivery with UML's is a no-brainer. Replacing its scheduler and threads library would involve it creating UML processes by calling UML's do_fork(). Valgrind would need to provide the low-level switch_to, I think. There are probably other things that Valgrind would need to provide, but I see no reason this wouldn't work. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 11:31 [W:0.140 / U:0.070 seconds] ©2003-2008 Jasper Spaans | ||||||||||