Re: [RFC] Unify KVM kernel-space and user-space code into a singleproject

[Antoine Martin]

On 03/22/2010 03:11 AM, Avi Kivity 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.
That's not always true.
The host admin can control the guest kernel via "kvm -kernel" easily 
enough, but he may or may not have access to the disk that is used in 
the guest. (think encrypted disks, service agreements, etc)

Antoine
> > Deploying things in the
> > host OTOH is business as usual.
>
> True.
>
> > And you're smart enough to know that.
>
> Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/