lkml.org 
[lkml]   [2010]   [Mar]   [22]   [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:

> > My 10+ years experience with kernel instrumentation solutions is that
> > kernel-driven, self-sufficient, robust, trustable, well-enumerated sources
> > of information work far better in practice.
>
> What about line number information? And the source? Into the kernel with
> them as well?

Sigh. Please read the _very first_ suggestion i made, which solves all that. I
rarely go into discussions without suggesting technical solutions - i'm not
interested in flaming, i'm interested in real solutions.

Here it is, repeated for the Nth time:

Allow a guest to (optionally) integrate its VFS namespace with the host side
as well. An example scheme would be:

/guests/Fedora-G1/
/guests/Fedora-G1/proc/
/guests/Fedora-G1/usr/
/guests/Fedora-G1/.../
/guests/OpenSuse-G2/
/guests/OpenSuse-G2/proc/
/guests/OpenSuse-G2/usr/
/guests/OpenSuse-G2/.../

( This feature would be configurable and would be default-off, to maintain
the current status quo. )

Line number information and the source (dwarf info) and ELF symbols are all
provided and accessible via such an interface - no need to run any 'symbol
demon' on the guest side.

And, obviously, having the guest VFS namespace (optionally) available on the
host side also has far more uses than perf's symbol needs.

I was surprised no-one ever came up with such a suggestion - it is so obvious
to allow the integration of the VFS namespaces. But given your explicit
declaration of your KVM desktop usability indifference i'm kind of not
surprised about that anymore.

Thanks,

Ingo


\
 
 \ /
  Last update: 2010-03-22 12:51    [W:0.282 / U:0.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site