From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cornelia Huck Subject: Re: [PATCH] KVM: trace events: update list of exit reasons Date: Fri, 15 Sep 2017 09:30:06 +0200 Message-ID: <20170915093006.3faf1aca.cohuck@redhat.com> References: <20170914095007.21331-1-lprosek@redhat.com> <20170914120646.49139c2a.cohuck@redhat.com> <20170914180733.GC23415@flask> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Cc: Ladi Prosek , kvm@vger.kernel.org To: Radim =?UTF-8?B?S3LEjW3DocWZ?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41812 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750866AbdIOHaK (ORCPT ); Fri, 15 Sep 2017 03:30:10 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9EEDB80F79 for ; Fri, 15 Sep 2017 07:30:10 +0000 (UTC) In-Reply-To: <20170914180733.GC23415@flask> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 14 Sep 2017 20:07:37 +0200 Radim Krčmář wrote: > 2017-09-14 12:06+0200, Cornelia Huck: > > /me wonders whether there is a way to avoid them running out of sync... > > If we do not want to generate it with an external script, I think the > simplest is to have a separate file that looks like > > #define kvm_exit_reasons \ > KVM_EXIT(UNKNOWN, 0), \ > KVM_EXIT(EXCEPTION, 1), \ > ... > KVM_EXIT(HYPERV, 27) \ > > and include it from both places. The current exit definitions would be > > #define KVM_EXIT(reason, code) > KVM_EXIT_ ## reason = code > > #include > > enum { > kvm_exit_reasons > }; > > #undef kvm_exit_reasons > > and the trace > > #define KVM_EXIT(reason, code) > { code, "KVM_EXIT_" # reason } > #include > > ... > > __print_symbolic(__entry->reason, kvm_exit_reasons), > > ... > > #undef kvm_exit_reasons > > (Would also work with just "KVM_EXIT(UNKNOWN), ..." and small tweaks.) > > > but otoh, not so many exit reasons are being added anyway. > > Yes. :) Yeah, your approach would work, but it's unlikely to be worth it :)