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

[Avi Kivity]

On 03/21/2010 09:59 PM, Ingo Molnar wrote:
> Frankly, i was surprised (and taken slightly off base) by both Avi and Anthony
> suggesting such a clearly inferior "add a demon to the guest space" solution.
> It's a usability and deployment non-starter.
>    

It's only clearly inferior if you ignore every consideration against 
it.  It's definitely not a deployment non-starter, see the tons of 
daemons that come with any Linux system.  The basic ones are installed 
and enabled automatically during system installation.

> Furthermore, allowing a guest to integrate/mount its files into the host VFS
> space (which was my suggestion) has many other uses and advantages as well,
> beyond the instrumentation/symbol-lookup purpose.
>    

Yes.  I'm just not sure about the auto-enabling part.

> So can we please have some resolution here and move on: the KVM maintainers
> should either suggest a different transparent approach, or should retract the
> NAK for the solution we suggested.
>    

So long as you define 'transparent' as in 'only the guest kernel is 
involved' or even 'only the guest and host kernels are involved' we 
aren't going to make a lot of progress.  I oppose shoving random bits of 
functionality into the kernel, especially things that are in daily use.  
While us developers do and will use profiling extensively, it doesn't 
need sit in every guest's non-swappable .text.

> We very much want to make progress and want to write code, but obviously we
> cannot code against a maintainer NAK, nor can we code up an inferior solution
> either.
>    

You haven't heard any NAKs, only objections.  If we discuss things 
perhaps we can achieve something that works for everyone.  If we keep 
turning the flames higher that's unlikely.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
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/