lkml.org 
[lkml]   [2010]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Unify KVM kernel-space and user-space code into a single project

* Avi Kivity <avi@redhat.com> 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


\
 
 \ /
  Last update: 2010-03-21 21:39    [from the cache]
©2003-2011 Jasper Spaans