From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5WTI-00069k-GS for qemu-devel@nongnu.org; Tue, 02 May 2017 08:00:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5WTH-0002Jf-8d for qemu-devel@nongnu.org; Tue, 02 May 2017 08:00:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40064) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d5WTG-0002JG-Vq for qemu-devel@nongnu.org; Tue, 02 May 2017 07:59:59 -0400 Date: Tue, 2 May 2017 12:59:53 +0100 From: "Daniel P. Berrange" Message-ID: <20170502115953.GJ3459@redhat.com> Reply-To: "Daniel P. Berrange" References: <1493719600-30853-1-git-send-email-thuth@redhat.com> <52fc3efd-55a7-af2d-ce8c-9b4565dfe6dc@de.ibm.com> <7c69341a-9584-8208-023a-42bfeeec6dee@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7c69341a-9584-8208-023a-42bfeeec6dee@redhat.com> Subject: Re: [Qemu-devel] [PATCH] Deprecate '-enable-kvm' and '-enable-hax' in favour of '-accel' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: Christian Borntraeger , qemu-devel@nongnu.org, Paolo Bonzini , Vincent Palatin On Tue, May 02, 2017 at 01:26:17PM +0200, Thomas Huth wrote: > On 02.05.2017 12:48, Christian Borntraeger wrote: > > On 05/02/2017 12:37 PM, Thomas Huth wrote: > >> On 02.05.2017 12:32, Christian Borntraeger wrote: > >>> On 05/02/2017 12:06 PM, Thomas Huth wrote: > >>>> The '-enable-...' option do not make too much sense: They do not > >>>> allow additional parameters, using '-accel xxx' is shorter than > >>>> '-enable-xxx' and we're also inconsistent here, since there is > >>>> no '-enable-xen' option available. So let's try to convince the > >>>> users to use '-accel xxx' instead. > >>> > >>> google has 36000 hits for "--enable-kvm" and 18000 hits for "--accel kvm" > >>> So I assume this will affect a lot of setups for only a very small benefit. > >> > >> I'm aware of the fact that likely a lot of users are still using > >> -enable-kvm, and I did not mean that we should remove it soon yet. But > >> IMHO we should start now to inform the users that they should slowly > >> switch to the better option "-accel" instead, so that we could maybe > >> remove this "-enable-xxx" stuff sometime in the distant future (let's > >> say QEMU v4.0?). > > > > I come from the Linux side, where "breaking a working setup" will result in > > an angry Linus. > > IMHO that's a good approach, but I think it should primarily applied for > the interfaces that are designed as "API" to other software layers, i.e. > things like QMP and the "-machine" parameter. > "-enable-kvm" is in my eyes rather a "syntactic sugar" convenience > option, so I'd not apply this rule to this option. > > > We certainly have not such strict rules here and we could > > base the decision on the question "how expensive is the maintenance > > of this option?". I think marking it as "legacy option" is fine, but I doubt > > that removing it will make qemu maintenance cheaper. > > Likely not. Actually, I have another point of view in mind here: You > have to consider that QEMU has a *lot* of options, and I think this is > very confusing for the users, especially the new ones. If we always > provide two or three ways to achieve a goal, especially in an > inconsistent way like we do it here, we likely rather create frustration > than joy for the normal users. Providing a clean, straightforward CLI > interface one day could help to improve the user experience quite a bit. The issue is that we have mutually exclusive requirements here. For a straightforward, easy to understand CLI, things like "--enable-kvm" are much quicker to discover & understand than "-machine accel=kvm". The latter gives much more flexibility since it can set all the other opts, but most of those are rarely used by people who are invoking QEMU manually/directly. We need the things like -machine for libvirt and similar, but they are not end user friendly. Killing all the shortcuts like --enable-kvm would cut down the args we expose, but forcing users onto more complex syntax for args like -machine is not improving their lives in general if they don't need that extra flexibility. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|