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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4BA32E1A.2060703@redhat.com>
Date:	Fri, 19 Mar 2010 09:56:10 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Pekka Enberg <penberg@...helsinki.fi>,
	Anthony Liguori <anthony@...emonkey.ws>,
	"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/18/2010 07:28 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@...hat.com>  wrote:
>
>    
>> On 03/18/2010 07:02 PM, Ingo Molnar wrote:
>>      
>>> I find the 'KVM mostly cares about the server, not about the desktop'
>>> attitude expressed in this thread troubling.
>>>        
>> It's not kvm, just it's developers (and their employers, where applicable).
>> If you post desktop oriented patches I'm sure they'll be welcome.
>>      
> Just such a patch-set was posted in this very thread: 'perf kvm'.
>
> There were two negative reactions immediately, both showed a fundamental
> server versus desktop bias:
>
>   - you did not accept that the most important usecase is when there is a
>     single guest running.
>    

Well, it isn't.

>   - the reaction to the 'how do we get symbols out of the guest' sub-question
>     was, paraphrased: 'we dont want that due to<unspecified>  security threat
>     to XYZ selinux usecase with lots of guests'.
>    

When I review a patch, I try to think of the difficult cases, not just 
the easy case.

> Anyone being aware of how Linux and KVM is being used on the desktop will know
> how detached that attitude is from the typical desktop usecase ...
>
> Usability _never_ sucks because of lack of patches or lack of suggestions. I
> bet if you made the next server feature contingent on essential usability
> fixes they'd happen overnight - for God's sake there's been 1000 commits in
> the last 3 months in the Qemu repository so there's plenty of manpower...
>    

First of all I am not a qemu maintainer.  Second, from my point of view 
all contributors are volunteers (perhaps their employer volunteered 
them, but there's no difference from my perspective).  Asking them to 
repaint my apartment as a condition to get a patch applied is abuse.  If 
a patch is good, it gets applied.

> Usability suckage - and i'm not going to be popular for saying this out loud -
> almost always shows a basic maintainer disconnect with the real world. See
> your very first reactions to my 'KVM usability' observations. Read back your
> and Anthony's replies: total 'sure, patches welcome' kind of indifference. It
> is _your project_, not some other project down the road ...
>    

I could drop everything and write a gtk GUI for qemu.  Is that what you 
want?

If someone is truly interested in a qemu usability, it's up to them to 
write the patches.  Personally I've never missed the eject button.

As to disconnect from the real world, most products based on kvm and 
qemu (and Linux) are server based.  Perhaps that's the reason people 
emphasise that?  Maybe if Linux had 10-20% desktop market penetration, 
there would be more interest in a bells and whistles qemu GUI.

> So that is my first-hand experience about how you are welcoming these desktop
> issues, in this very thread. I suspect people try a few times with
> suggestions, then get shot down like our suggestions were shot down and then
> give up.
>    

I don't recall anyone trying this much less being shot down.  Perhaps 
people are concentrating on virt-manager and the like and leaving qemu 
alone.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
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/