* Avi Kivity <avi@xxxxxxxxxx> wrote: > On 03/21/2010 10:08 PM, Olivier Galibert wrote: > >On Sun, Mar 21, 2010 at 10:01:51PM +0200, Avi Kivity wrote: > >>On 03/21/2010 09:17 PM, Ingo Molnar wrote: > >>>Adding any new daemon to an existing guest is a deployment and usability > >>>nightmare. > >>> > >>The logical conclusion of that is that everything should be built into > >>the kernel. Where a failure brings the system down or worse. Where you > >>have to bear the memory footprint whether you ever use the functionality > >>or not. Where to update the functionality you need to deploy a new > >>kernel (possibly introducing unrelated bugs) and reboot. > >> > >>If userspace daemons are such a deployment and usability nightmare, > >>maybe we should fix that instead. > >Which userspace? Deploying *anything* in the guest can be a > >nightmare, including paravirt drivers if you don't have a natively > >supported in the OS virtual hardware backoff. > > That includes the guest kernel. If you can deploy a new kernel in the > guest, presumably you can deploy a userspace package. Note that with perf we can instrument the guest with zero guest-kernel modifications as well. We try to reduce the guest impact to a bare minimum, as the difficulties in deployment are function of the cross section surface to the guest. Also, note that the kernel is special with regards to instrumentation: since this is the kernel project, we are doing kernel space changes, as we are doing them _anyway_. So adding symbol resolution capabilities would be a minimal addition to that - while adding a while new guest package for the demon would significantly increase the cross section surface. Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
