On 03/16/2010 01:25 PM, Ingo Molnar wrote:
quoted text
>
>> I haven't followed vmchannel closely, but I think it is.  vmchannel is
>> terminated in qemu on the host side, not in the host kernel.  So perf would
>> need to connect to qemu.
>>      
> Hm, that sounds rather messy if we want to use it to basically expose kernel
> functionality in a guest/host unified way. Is the qemu process discoverable in
> some secure way?

We know its pid.

quoted text
> Can we trust it?

No choice, it contains the guest address space.

quoted text
> Is there some proper tooling available to do
> it, or do we have to push it through 2-3 packages to get such a useful feature
> done?
>    

libvirt manages qemu processes, but I don't think this should go through 
libvirt.  qemu can do this directly by opening a unix domain socket in a 
well-known place.

quoted text
> ( That is the general thought process how many cross-discipline useful
>    desktop/server features hit the bit bucket before having had any chance of
>    being vetted by users, and why Linux sucks so much when it comes to feature
>    integration and application usability. )
>    

You can't solve everything in the kernel, even with a well populated tools/.

-- 
error compiling committee.c: too many arguments to function

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/