qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [qemu-s390x] [PATCH v2 2/8] s390x/css: IO instr handler


From: Cornelia Huck
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH v2 2/8] s390x/css: IO instr handler ending control
Date: Tue, 17 Oct 2017 14:13:52 +0200

On Tue, 17 Oct 2017 13:28:57 +0200
Thomas Huth <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]