Jan Kiszka <jan.kiszka@xxxxxx> writes: > On 2012-10-03 19:16, Anthony Liguori wrote: >> Jan Kiszka <jan.kiszka@xxxxxx> writes: >> >>> On 2012-10-03 17:03, Marcelo Tosatti wrote: >>>> On Wed, Oct 03, 2012 at 09:40:17AM -0500, Anthony Liguori wrote: >>>>> Marcelo Tosatti <mtosatti@xxxxxxxxxx> writes: >>>>> >>>>>> Commit 3ad763fcba5bd0ec5a79d4a9b6baeef119dd4a3d from qemu-kvm.git. >>>>>> >>>>>> From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx> >>>>>> >>>>>> Upstream is moving towards this mechanism, so start using it in qemu-kvm >>>>>> already to configure the specific defaults: kvm enabled on, just like >>>>>> in-kernel irqchips. >>>>>> >>>>>> Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx> >>>>> >>>>> >>>>> Reviewed-by: Anthony Liguori <aliguori@xxxxxxxxxx> >>>>> >>>>> Although it's a little odd to have From: Jan without a SoB... >>>> >>>> Agree, Jan can you ACK? >>> >>> I wasn't able to join the call yesterday: Is there a removal schedule >>> associated with those switches? Also, why pushing things upstream, even >>> when only for one release, that have been loudly deprecated for a while >>> in qemu-kvm? Some switches are lacking deprecated warnings on the >>> console, and -no-kvm is missing completely. I tend to focus on patch 1 & >>> 5, dropping the rest - based on relevance for production use. >> >> The distros need to keep these flags to do the switch. > > Why? Should be documented in commit log. > >> I see no point >> in deprecating them since they're trivially easy to maintain. > > Given the level of cr** we already have in the command line, they are > kind of noise, yes. But even then, these patches are not consistent as > pointed out above. > > Also, they should not be documented to avoid being spread. That's what > we did with other deprecated switches in QEMU. The patchset isn't checkpatch clean so I'll fix that, remove the docs, and send a new version tomorrow along with the machine changes. Regards, Anthony Liguori > > Jan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
