On 10/26/2016 05:13 PM, Dimitri John Ledkov wrote: > Currently s390-netdevice in the code supports following networktypes: > * qeth > * ctc > * iucv > * virtio > > virtio is, in fact, a no-op. Yup. > iucv refers to "IUCV network device" which has been deprecated at > least since October 2005 (linux v2.6+) I guess IUCV is only deprecated for networking, not for console access, right? I would not mind dropping it then. > ctc refers to channel-to-channel devices which has also been > deprecated at least since October 2005 (linux v2.6+) CTC is used by default by Hercules. I suppose it can also do qeth now? Or maybe that's just in a fork? Last I checked it still worked, as well. > The migration path from above to is onto Hipersockets or QDIO. > Both migration paths are handled on the linux side by the qeth kernel > module as fas as I understand. > > Hence, the only option of the 4 that may do anything is qeth, if there > are any qeth devices detected that need activation. > > Furthermore, I'm not sure if iucv network device works correctly - > confirm_iucv function returns WANT_ERROR, unless after activating iucv > one must continue with the ctc code path. > > Imho, we should simply skip the whole d-i module if there are no qeth > devices to activate. If there are any qeth devices to activate, > display multi select question of the qeth devices to activate. > Multi-select question, such that continue without selecting any is a > valid option (for example if one wants to install using the PCIe > interfaces). I very much sympathize with this idea in general. If we can also detect if CTC devices are on the bus, only showing the prompt if devices can be found would be useful. Did the kernel start off not offering all devices in sysfs because LPARs can have a huge amount of them? Or did it always rely on blacklisting in this case? I suppose that the original reason was that you actually had to enter device numbers because it couldn't probe, but then on the other hand the selection for qeth was shown for a long time now. Kind regards and thanks Philipp Kern
Attachment:
signature.asc
Description: OpenPGP digital signature