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

Bug#825931: s390-netdevice virtio interface choice misleading



On 23 October 2016 at 22:57, Philipp Kern <pkern@debian.org> wrote:
> Hi,
>
> On 05/31/2016 09:01 PM, Dimitri John Ledkov wrote:
>> I find logic in s390-netdevice. The priority of many questions is too
>> high, thus e.g. if one uses qeth port 0, one has to explicitely
>> preseed that, even though a common case qeth port 0 will work in
>> majority (sensible default) cases.
>
> I downgraded it from critical to medium. It was only recently added anyway.
>
>> Looking at the code it is impossible to configure IUCV. And there is
>> nothing to do in case of virtio. I think no questions should be even
>> asked if there are no CTC/QETH cards to activate. And be optional
>> similarly to how you propose in your patch.
>
> Can you clarify your first sentence? Should IUCV support be removed?
>
> It's unfortunate that your last patch of exiting when no CTC/QETH
> devices are present only went to the BTS and hence I never saw it. It
> would also actively break the still present IUCV support, hence I
> actually need some input as to why you think it's broken. And possibly a
> way of checking if there actually is a possibility of using IUCV for the
> VM in question.
>

Here summary of my investigation into this:

Currently s390-netdevice in the code supports following networktypes:
* qeth
* ctc
* iucv
* virtio

virtio is, in fact, a no-op.
iucv refers to "IUCV network device" which has been deprecated at
least since October 2005 (linux v2.6+)
ctc refers to channel-to-channel devices which has also been
deprecated at least since October 2005 (linux v2.6+)
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).

Above definitely makes sense for Ubuntu, as it only targets zEC12 and
up. However, I am suspecting that above is also valid reasoning for z9
and up = all s390x ports. Is there any way to find out whether there
are any Debian users that still use ctc/iucv and have no ability to
migrate to qeth?

References:
Network devices being deprecated with the "October 2005 stream"
section of http://www.ibm.com/developerworks/linux/linux390/october2005_technical.html
Share slides from 2008 (but recycled / reused same slides in other
years as well, 2008 is the earliest I can find) Slide 12 Message to
CTC and IUCV users http://linuxvm.org/present/SHARE110/S9267st.pdf

-- 
Regards,

Dimitri.


Reply to: