On 10/17/2017 02:13 PM, Cornelia Huck wrote:
> On Tue, 17 Oct 2017 13:28:57 +0200
> Thomas Huth <th...@redhat.com> wrote:
>
>> On 17.10.2017 13:10, Halil Pasic wrote:
>>>
>>>
>>> On 10/12/2017 01:44 PM, Halil Pasic wrote:
>>>>
>>>>
>>>> On 10/12/2017 08:58 AM, Thomas Huth wrote:
>>>>> On 10.10.2017 13:41, Halil Pasic wrote:
>>> [..]
>>>>> So yes, please don't do a "typedef unsigned int IOInstEnding" either. I
>>>>> think the best match for QEMU would be a
>>>>>
>>>>> typedef enum IOInstEnding {
>>>>> CC_...,
>>>>> CC_...,
>>>>> CC_...,
>>>>> CC_...
>>>>> } IOInstEnding;
>>>>>
>>>>
>>>> I also prefer this over #define NAME val.
>>>>
>>>
>>> @Conny @Thomas
>>>
>>> I'm almost done with v3, but I've realized we did not agree on the
>>> names for the enum constants, so before posting something to ugly
>>> again, I would like to inquire your opinion.
>>>
>>> My current version of the enum is the following (but I can easily change
>>> to whatever you like with sed):
>>>
>>> +/*
>>> + * IO instructions conclude according this. Currently we have only
>>> + * cc codes. Valid values are 0,1,2,3 and the generic semantic for IO
>>> instructions
>>> + * is described briefly. For more details consult the PoP.
>>> + */
>>> +typedef enum IOInstEnding {
>>> + IOINST_CC_0 = 0, /* produced expected result */
>>> + IOINST_CC_1 = 1, /* status conditions were present, or alternate
>>> result */
>>> + IOINST_CC_2 = 2, /* ineffective, busy with previously initiated
>>> function */
>>> + IOINST_CC_3 = 3 /* ineffective, not operational */
>>> +} IOInstEnding;
>>> +
>>>
>>> Alternatives I had in mind are IOINST_CC_0_EXPECTED,
>>> IOINST_CC_1_STATUS_PRESENT,
>>> IOINST_CC_2_BUSY, IOINST_CC_3_NOT_OPERATIONAL or the same without the
>>> numerical
>>> code (e.g. just IONIST_CC_EXPECTED).
>>
>> FWIW, I'd prefer your last suggestion (e.g. IOINST_CC_EXPECTED).
>
> Either IOINST_CC_0 or IOINST_CC_EXPECTED, whatever you like best.
>
Thanks, I will go with the non-numerical variant as preferred by
Thomas (I've already changed my patches).
