On 03/17/2010 03:10 AM, Ingo Molnar wrote:
> * Anthony Liguori<anthony@codemonkey.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