From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web12.7347.1580314487042551684 for ; Wed, 29 Jan 2020 08:14:47 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KBGINyr7; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580314486; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f779P0wnKaXYjI5mJU6xjU03x1vHo0GQfrDE1o6lQnQ=; b=KBGINyr7MeST/8ZXs84sB8Tkl3orkMeVLVyxviLEsnDFZ36Nl7p7wBTmgkG2XubLmjiybJ Vk4sOsjTxjzFdkyfCae1qMjnjYvTd0n626inzUw58KRXYHA8Day7LXtNop9i5Zb7zccJrR eEWc0A0GTXAJ3CYv+iag2+k9yMMoevo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-36-sB1C5B1TMXCaV9nrbBDviQ-1; Wed, 29 Jan 2020 11:14:42 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6098D800D4C; Wed, 29 Jan 2020 16:14:40 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-32.ams2.redhat.com [10.36.116.32]) by smtp.corp.redhat.com (Postfix) with ESMTP id 406175D9C5; Wed, 29 Jan 2020 16:14:36 +0000 (UTC) Subject: Re: [PATCH 3/5] OvmfPkg/IndustryStandard/Xen: Apply EDK2 coding style to XEN_VCPU_TIME_INFO To: Anthony PERARD , devel@edk2.groups.io Cc: Michael D Kinney , Ard Biesheuvel , xen-devel@lists.xenproject.org, Liming Gao , Jordan Justen , Julien Grall References: <20200129121235.1814563-1-anthony.perard@citrix.com> <20200129121235.1814563-4-anthony.perard@citrix.com> From: "Laszlo Ersek" Message-ID: Date: Wed, 29 Jan 2020 17:14:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200129121235.1814563-4-anthony.perard@citrix.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-MC-Unique: sB1C5B1TMXCaV9nrbBDviQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 01/29/20 13:12, Anthony PERARD wrote: > We are going to use new fields from the Xen headers. Apply the EDK2 > coding style so that the code that is going to use it doesn't look out > of place. > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/Include/IndustryStandard/Xen/xen.h | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) This is highly appreciated. Comments below: > > diff --git a/OvmfPkg/Include/IndustryStandard/Xen/xen.h b/OvmfPkg/Include/IndustryStandard/Xen/xen.h > index e55d93263285..ac9155089902 100644 > --- a/OvmfPkg/Include/IndustryStandard/Xen/xen.h > +++ b/OvmfPkg/Include/IndustryStandard/Xen/xen.h > @@ -183,10 +183,10 @@ struct vcpu_time_info { > * The correct way to interact with the version number is similar to > * Linux's seqlock: see the implementations of read_seqbegin/read_seqretry. > */ > - UINT32 version; > + UINT32 Version; > UINT32 pad0; > - UINT64 tsc_timestamp; /* TSC at last update of time vals. */ > - UINT64 system_time; /* Time, in nanosecs, since boot. */ > + UINT64 TSCTimestamp; /* TSC at last update of time vals. */ (1) Should be "TscTimestamp". Acronyms are de-capitalized when composed into longer identifiers, to maintain a consistent CamelCase. > + UINT64 SystemTime; /* Time, in nanosecs, since boot. */ > /* > * Current system time: > * system_time + > @@ -194,11 +194,11 @@ struct vcpu_time_info { > * CPU frequency (Hz): > * ((10^9 << 32) / tsc_to_system_mul) >> tsc_shift > */ > - UINT32 tsc_to_system_mul; > - INT8 tsc_shift; > + UINT32 TSCToSystemMultiplier; > + INT8 TSCShift; (2) Ditto (both fields). > INT8 pad1[3]; > }; /* 32 bytes */ > -typedef struct vcpu_time_info vcpu_time_info_t; > +typedef struct vcpu_time_info XEN_VCPU_TIME_INFO; > > struct vcpu_info { > /* > @@ -234,7 +234,7 @@ struct vcpu_info { > #endif /* XEN_HAVE_PV_UPCALL_MASK */ > xen_ulong_t evtchn_pending_sel; > struct arch_vcpu_info arch; > - struct vcpu_time_info time; > + struct vcpu_time_info Time; > }; /* 64 bytes (x86) */ > #ifndef __XEN__ > typedef struct vcpu_info vcpu_info_t; > @@ -250,7 +250,7 @@ typedef struct vcpu_info vcpu_info_t; > * of this structure remaining constant. > */ > struct shared_info { > - struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS]; > + struct vcpu_info VcpuInfo[XEN_LEGACY_MAX_VCPUS]; Yes, this is a good example. "Vcpu" and not "VCPU" or "VCpu". > > /* > * A domain can create "event channels" on which it can send and receive > @@ -299,6 +299,7 @@ struct shared_info { > }; > #ifndef __XEN__ > typedef struct shared_info shared_info_t; > +typedef struct shared_info XEN_SHARED_INFO; > #endif > > /* Turn a plain number into a C UINTN constant. */ > Assuming the OVMF platforms continue to build at this stage into the series, and provided that (1) and (2) are fixed: Reviewed-by: Laszlo Ersek