On Mon, 11 Sep 2017 15:08:52 +0200 Halil Pasic <pa...@linux.vnet.ibm.com> wrote:
> On 09/11/2017 11:48 AM, Cornelia Huck wrote: > > On Fri, 8 Sep 2017 17:24:45 +0200 > > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> The case in question actually never happens. Let us get rid of the dead > >> code. > > > > I had tried to be complete in my initial implementation. With the > > current implementation, it can never happen, yes. We can easily > > resurrect it from git history should we need it in the future. > > > > I've tried to understand the branch but I failed. Weather the subchannel > is busy or not should be already decided, and if the device is busy > that is probably supposed to be indicated via device status (word 2 bit 3). > > So I wrote dubious because I could not figure it out. But unused > is certainly nicer. > > I think shall the need emerge the preferred way of handling would > be to use the custom handling (-EIO) branch. What this is trying to do is deferred cc 1 handling. On a real system, a ssch may return with cc 0 to indicate that the channel program has been accepted; but when the channel subsystem actually tries to execute it, a status is already pending. Basically, it's a race condition: Therefore the 'deferred' cc 1. Maybe I should have called this 'deferred subchannel busy'... but anyway, this cannot happen in our current implementation.
