This is highly experimental, alpha-quality software. We're not even sure if this is the right approach to implementing these tools. Our ideas about the software change almost daily. If it works for you well done, if it breaks then you get to keep all the pieces.
At the moment this software is known to only work on 32 bit kernels. It's very simple to make it work on 64 bit, but I don't have convenient access to a 64 bit system at the moment. Blame my landlord and his useless builders. As soon as I regain access to my 64 bit machines I'll fix and test 64 bit support.
We only support QEMU and KVM guests. Xen isn't supported at the moment — this requires a patch to libvirt. This email outlines what needs to be done.
Virt-mem contains a database of known kernels (in the
kernels/ subdirectory in the source).
Each kernel in the database is represented by two files,
a name.info file and
a name.data file (usually compressed).
The info file has some metadata about the kernel. The
data file contains information about the layout of kernel
structures and is the direct output of the pahole -E vmlinux
command.
To add your own kernel(s), you will need:
vmlinux) that was compiled with
the -g option so it includes debugging symbols. These
kernels are not normally run, but distributions produce them in addition
to normal kernels so that people can run kgdb etc.
Now write a script which downloads and extracts the info and
data information. See
extract/fedora-koji/
for how we do it with Fedora kernels.
By the way, it's better to solve this problem once and for all, for a whole Linux distribution. For example, with Fedora we have some scripts which continuously download the latest kernels from our build system (Koji) and update the database.
$Id: faq.html,v 1.1 2008/08/17 18:09:50 rjones Exp $