On Mon, 27 Apr 2020 12:10:17 +0200 Peter Oberparleiter <oberpar@xxxxxxxxxxxxx> wrote: > On 23.04.2020 18:20, Cornelia Huck wrote: > > On Thu, 23 Apr 2020 16:52:24 +0200 > > Vineeth Vijayan <vneethv@xxxxxxxxxxxxxxxxxx> wrote: > >> Then we could also change the way ccw_device_call_sch_unregister() > >> works, where > >> the subchannel-unregister is happening from an upper layer. > > > > Hm, what's the problem here? This seems to be mostly a case of "we did > > I/O to the device and it appeared not operational; so we go ahead and > > unregister the subchannel"? Childless I/O subchannels are a bit useless. > > Hey Conny, > > sparked by your proposal, Vineeth and myself looked at the corresponding > CIO code and wondered if things couldn't be done in a generally > better/cleaner way. So here we'd like to get your opinion. > > In particular, as it is currently, a child-driver (IO subchannel driver, > vfio-ccw, etc.) unregisters a device owned by a parent-device-driver > (CSS), which feels from a high-level-view like a layering violation: > only the parent driver should register and unregister the parent device. > Also in case no subchannel driver is available (e.g. due to > driver_override=none), there would be no subchannel ADD event at all. Doesn't the base css code generate the uevent in that case? > > So, tapping into you historical expertise about CIO, is there any reason > for doing it this way beyond being nice to userspace tooling that > subchannels with non-working CCW devices are automatically hidden by > unregistering them? We always had ccw devices behind I/O subchannels, but that has not been the case since we introduced vfio-ccw, so hopefully everybody can deal with that. The rationale behind this was that device-less I/O subchannels were deemed to be useless; I currently can't remember another reason. What about EADM, btw? CHSC does not have a device, and message does not have a driver. > > Removing the child-unregisters-parent logic this would also enable > manual rebind of subchannels for which only a different driver than the > default one can successfully talk to the child device, though I'm > unaware of any current application for that. Yes. Let me think about that some more (no clear head currently, sorry.)
