linux-kernel - Re: [RFC] Unify KVM kernel-space and user-space code into a single project

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4BA23AF3.1020209@codemonkey.ws>
Date:	Thu, 18 Mar 2010 09:38:43 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Avi Kivity <avi@...hat.com>,
	"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

On 03/17/2010 03:10 AM, Ingo Molnar wrote:
> * Anthony Liguori<anthony@...emonkey.ws>  wrote:
>
>    
>> On 03/16/2010 12:39 PM, Ingo Molnar wrote:
>>      
>>>> If we look at the use-case, it's going to be something like, a user is
>>>> creating virtual machines and wants to get performance information about
>>>> them.
>>>>
>>>> Having to run a separate tool like perf is not going to be what they would
>>>> expect they had to do.  Instead, they would either use their existing GUI
>>>> tool (like virt-manager) or they would use their management interface
>>>> (either QMP or libvirt).
>>>>
>>>> The complexity of interaction is due to the fact that perf shouldn't be a
>>>> stand alone tool.  It should be a library or something with a programmatic
>>>> interface that another tool can make use of.
>>>>          
>>> But ... a GUI interface/integration is of course possible too, and it's being
>>> worked on.
>>>
>>> perf is mainly a kernel developer tool, and kernel developers generally dont
>>> use GUIs to do their stuff: which is the (sole) reason why its first ~850
>>> commits of tools/perf/ were done without a GUI. We go where our developers
>>> are.
>>>
>>> In any case it's not an excuse to have no proper command-line tooling. In fact
>>> if you cannot get simpler, more atomic command-line tooling right then you'll
>>> probably doubly suck at doing a GUI as well.
>>>        
>> It's about who owns the user interface.
>>
>> If qemu owns the user interface, than we can satisfy this in a very simple
>> way by adding a perf monitor command.  If we have to support third party
>> tools, then it significantly complicates things.
>>      
> Of course illogical modularization complicates things 'significantly'.
>    

Ok.  Then apply this to the kernel.  I'm then happy to take patches.

Regards,

Anthony Liguori


View attachment "qemu-linux.patch" of type "text/plain" (1205 bytes)