lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100322114824.GF3483@elte.hu>
Date:	Mon, 22 Mar 2010 12:48:24 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	Antoine Martin <antoine@...afix.co.uk>,
	Olivier Galibert <galibert@...ox.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Pekka Enberg <penberg@...helsinki.fi>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project


* Avi Kivity <avi@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ