From mboxrd@z Thu Jan  1 00:00:00 1970
From: Corneliu ZUZU <czuzu@bitdefender.com>
Subject: Re: [PATCH v2 2/7] xen/x86: merge 2 hvm_event_...
 functions into 1
Date: Thu, 11 Feb 2016 08:03:38 +0200
Message-ID: <56BC243A.2020406@bitdefender.com>
References: <1455119259-2161-1-git-send-email-czuzu@bitdefender.com>
	<1455119433-2308-1-git-send-email-czuzu@bitdefender.com>
	<56BB710302000078000D0B05@prv-mh.provo.novell.com>
	<56BB6D92.3050300@bitdefender.com>
	<56BB7D4302000078000D0C22@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <56BB7D4302000078000D0C22@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Tamas K Lengyel <tamas@tklengyel.com>, Keir Fraser <keir@xen.org>, Razvan Cojocaru <rcojocaru@bitdefender.com>, Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org, Jun Nakajima <jun.nakajima@intel.com>
List-Id: xen-devel@lists.xenproject.org

On 2/10/2016 7:11 PM, Jan Beulich wrote:
>>>> On 10.02.16 at 18:04, <czuzu@bitdefender.com> wrote:
>> On 2/10/2016 6:18 PM, Jan Beulich wrote:
>>>>>> On 10.02.16 at 16:50, <czuzu@bitdefender.com> wrote:
>>>> --- a/xen/include/asm-x86/hvm/event.h
>>>> +++ b/xen/include/asm-x86/hvm/event.h
>>>> @@ -17,6 +17,12 @@
>>>>    #ifndef __ASM_X86_HVM_EVENT_H__
>>>>    #define __ASM_X86_HVM_EVENT_H__
>>>>    
>>>> +enum hvm_event_breakpoint_type
>>>> +{
>>>> +    HVM_EVENT_SOFTWARE_BREAKPOINT,
>>>> +    HVM_EVENT_SINGLESTEP_BREAKPOINT,
>>>> +};
>>> I don't see what good it does to put existing constants into an
>>> enum.
>> As Andrew pointed out, an enum was requested in v1 instead of the
>> single_step param.
>> One could use the already existing VM_EVENT_REASON_* constants, but
>> conceptually this
>> function only involves a subset of those (i.e. *breakpoint vm-events*).
> Re-using existing constants would seem fine to me.
>
> I only now realize that I've made a mistake while looking at the
> above - the capitals made it implicitly "obvious" to me that they're
> on the right side of an assignment. Please use capitals only for
> #define-d constants, not enumerated ones.
>
> Jan
>
>

Also, why this bias towards #define vs enums? I usually always prefer 
the latter,
they make the code more readable, e.g. it's clearer what can or cannot 
be passed
to a corresponding function parameter. And from an IDE user's 
point-of-view, I don't
understand why I have to read a comment and search for a list of identifiers
rather than just clicking on a type name and getting there in a flash.
They also make debugging easier, etc.. :).

Corneliu.