On Wed, Jan 10, 2024 at 03:24:30PM +0100, Steffen Maier wrote:
Hi Coiby,
thanks for your reply, much appreciated.
On 1/10/24 06:30, Coiby Xu wrote:
>Thanks for your patience!
>
>On Thu, Nov 09, 2023 at 04:50:38PM +0100, Steffen Maier wrote:
>>Consolidate the persistent and dynamic configuration of s390-specific
>>network devices by delegating the configuration to the existing framework
>>zdev from s390-tools.
>>
>>This is part of a larger consolidation comprising:
>>https://github.com/ibm-s390-linux/s390-tools/pull/158
>>https://github.com/dracutdevs/dracut/pull/2534
>>https://github.com/storaged-project/blivet/pull/1162
>>https://github.com/rhinstaller/anaconda/pull/5250
>>https://github.com/steffen-maier/s390utils/pull/1
>>However, there are no dependencies on these other pull requests, so the
>>change here can go in independently. It only depends on zdev from
>>s390-tools, which exists since years.
>
>Although zdev exists, doesn't this patch set depend on a newer zdev?
To the best of my knowledge, I only use old functionality of chzdev and lszdev.
Do you have any particular code location / option in mind that might
look like it needs something new?
It seems I don't have sufficient understanding about what the 1st patch
is doing. Currently the low-level configuration is done by ccw_init
which needs to extract info from NM (NetworkManager) connection files.
Does I understand it correctly that there will be no need for invoke
ccw_init after applying the 1st patch because the configuration is
now persistent?
I successfully tested this kexec-tools change standalone on an
otherwise unmodified RHEL9, i.e. with whatever chzdev & lszdev it
already ships packaged in s390utils-core (v2.27.0).
Thank you for testing this change! To improve my understanding, I did an
experiment by removing info like s390-subchannel from NM connection files. To
my surprise, the network connection can be established successfully
without applying this patch set for both RHEL8 and RHEL9? Is it
expected?
>And I
>notice
github.com/steffen-maier/s390utils/pull/1 hasn't been merged.
That only introduces helpers to migrate existing old persistent config
to zdev persistent config, e.g. during distro upgrade, and gradually
removes the Red Hat specific downstream code handling the old
persistent config (no more parsing dasd.conf or zfcp.conf, not
depending on s390-specific network device config in ifcfg files /
NetworkManager connections).
As such it will be one of the last things to be integrated. (Note that
this PR cannot really be merged as there does not seem to be an
"upstream" s390utils on github. I only opened this dangling PR as a
shipment vehicle so Dan can take the commits from the branch of this
PR, because I cannot use
https://src.fedoraproject.org/rpms/s390utils
to contribute.)
The full dependency graph of this entire endeavor of consolidating
s390 device configuration is tricky.
I think what matters here is that the kexec-tools change as well as
the already merged
https://github.com/ibm-s390-linux/s390-tools/pull/158 are both leave
nodes in the dependency tree. I.e. they do not depend on anything
else, but they are pre-reqs for other packages (or certains commits in
PRs for other packages).
This kexec-tools change here modifies the generation of host-specific
znet device configuration stored in initrd during creation of a kdump
initrd from the old persistent config to retrieving the necessary
device configuration from the active config [sysfs] by only using old
chzdev functionality. Hence it already becomes completely independent
from the old persistent mechanism and thus does not need any migration
of old persistent config => independent of s390utils/pull/1.
Hope this makes sense.
Yes, it makes sense to me now. Thanks for such a detailed explanation!
--
Mit freundlichen Gruessen / Kind regards
Steffen Maier
Linux on IBM Z and LinuxONE
https://www.ibm.com/privacy/us/en/
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschaeftsfuehrung: David Faller
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
_______________________________________________
kexec mailing list -- kexec(a)lists.fedoraproject.org
To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Best regards,
Coiby