All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.vnet.ibm.com>
Cc: Thomas Huth <thuth@redhat.com>,
	Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>,
	qemu-s390x@nongnu.org, Pierre Morel <pmorel@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 2/8] s390x/css: IO instr handler ending control
Date: Mon, 9 Oct 2017 13:09:45 +0200	[thread overview]
Message-ID: <20171009130945.3c58e6cb.cohuck@redhat.com> (raw)
In-Reply-To: <7f454872-fae3-35b0-eff4-227b2aa0f77d@linux.vnet.ibm.com>

On Mon, 9 Oct 2017 12:54:03 +0200
Halil Pasic <pasic@linux.vnet.ibm.com> wrote:

> On 10/09/2017 10:20 AM, Thomas Huth wrote:
> > On 04.10.2017 17:41, Halil Pasic wrote:  

> >> +/* IO instructions conclude according this */
> >> +typedef struct IOInstEnding {
> >> +        /*
> >> +         * General semantic of cc codes of IO instructions is (brief):
> >> +         * 0 -- produced expected result
> >> +         * 1 --  status conditions were present or produced alternate result
> >> +         * 2 -- ineffective, because busy with previously initiated function
> >> +         * 3 -- ineffective, not operational
> >> +         */
> >> +        int cc;
> >> +} IOInstEnding;  
> > 
> > Why do you need a struct for this? Do you plan to extend it later? If
> > so, I think you should mention that in the patch description. If not,
> > please use a named enum or a "typedef unsigned int IOInstEnding" instead.
> > 
> >  Thomas  
> 
> We may, we may not. In the previous version we also had to support
> do end a certain instruction with an addressing exception, but this
> is going away in patch #3. Honestly I don't expect this being extended.
> 
> I have other reasons for the struct. Type safety and clear semantics,
> and frankly at least for s390 and linux I don't see any downsides given
> what is written in the "zSeries ELF Application Binary Interface Supplement".
> Can you please explain to me what is the problem with using this struct, and
> what is the benefit switching to a unsigned int?

Honestly, I fail to see the benefit of using a struct here... it's just
a condition code, and while adding a comment what the various codes
mean for I/O instructions is a good idea, I think having to use a
IOInstEnding struct just renders the code less readable.

[I haven't had time to look at the rest of the patches yet.]

  parent reply	other threads:[~2017-10-09 11:09 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04 15:41 [Qemu-devel] [PATCH v2 0/8] improve error handling for IO instr Halil Pasic
2017-10-04 15:41 ` [Qemu-devel] [PATCH v2 1/8] s390x/css: be more consistent if broken beyond repair Halil Pasic
2017-10-09  7:49   ` Dong Jia Shi
2017-10-10 13:25   ` Cornelia Huck
2017-10-10 14:39     ` Halil Pasic
2017-10-04 15:41 ` [Qemu-devel] [PATCH v2 2/8] s390x/css: IO instr handler ending control Halil Pasic
2017-10-09  8:20   ` Thomas Huth
2017-10-09 10:54     ` Halil Pasic
2017-10-09 11:07       ` Thomas Huth
2017-10-09 15:00         ` Halil Pasic
2017-10-10 10:28           ` Thomas Huth
2017-10-10 11:39             ` Cornelia Huck
2017-10-10 11:48               ` Halil Pasic
2017-10-10 11:41             ` Halil Pasic
2017-10-12  6:58               ` Thomas Huth
2017-10-12 11:44                 ` Halil Pasic
2017-10-17 11:10                   ` Halil Pasic
2017-10-17 11:28                     ` [Qemu-devel] [qemu-s390x] " Thomas Huth
2017-10-17 12:13                       ` Cornelia Huck
2017-10-17 13:03                         ` Halil Pasic
2017-10-09 11:09       ` Cornelia Huck [this message]
2017-10-09 15:19         ` [Qemu-devel] " Halil Pasic
2017-10-04 15:41 ` [Qemu-devel] [PATCH v2 3/8] s390x: improve error handling for SSCH and RSCH Halil Pasic
2017-10-10  8:13   ` Dong Jia Shi
2017-10-10 10:06     ` Halil Pasic
2017-10-11  3:53       ` Dong Jia Shi
2017-10-10 13:07   ` Cornelia Huck
2017-10-10 14:36     ` Halil Pasic
2017-10-12 12:06       ` Halil Pasic
2017-10-12 12:11         ` Cornelia Huck
2017-10-12 12:17           ` Halil Pasic
2017-10-11  3:47   ` Dong Jia Shi
2017-10-11 10:54     ` Halil Pasic
2017-10-12  5:44       ` Dong Jia Shi
2017-10-04 15:41 ` [Qemu-devel] [PATCH v2 4/8] s390x: refactor error handling for XSCH handler Halil Pasic
2017-10-04 15:41 ` [Qemu-devel] [PATCH v2 5/8] s390x: refactor error handling for CSCH handler Halil Pasic
2017-10-04 15:41 ` [Qemu-devel] [PATCH v2 6/8] s390x: refactor error handling for HSCH handler Halil Pasic
2017-10-04 15:41 ` [Qemu-devel] [PATCH v2 7/8] s390x: refactor error handling for MSCH handler Halil Pasic
2017-10-04 15:41 ` [Qemu-devel] [PATCH v2 8/8] s390x: factor out common ioinst handler logic Halil Pasic
2017-10-10 13:10   ` Cornelia Huck
2017-10-10 14:37     ` Halil Pasic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171009130945.3c58e6cb.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=pasic@linux.vnet.ibm.com \
    --cc=pmorel@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.