summaryrefslogtreecommitdiff
path: root/src/settings/nm-settings-connection.c
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2019-08-21 14:30:34 +0200
committerThomas Haller <thaller@redhat.com>2019-08-28 16:27:00 +0200
commitcca0c2b56a4c637d8fc222353126b6f46187ba53 (patch)
tree79f326a67fdcc1b2bb6022780e3538fcfa111691 /src/settings/nm-settings-connection.c
parentc3d41fa4529ec9c9e266d117cc5b8ec4e2d917b8 (diff)
downloadNetworkManager-cca0c2b56a4c637d8fc222353126b6f46187ba53.tar.gz
device: move SR-IOV initialization to activate_stage1_device_prepare()
Note that all subclasses of NMDevice that implement act_stage1_prepare(), call the parents implementation as very first thing. Previously, NMDevice's act_stage1_prepare() was setting up SR-IOV. But that is problemantic. Note that it may have returned NM_ACT_STAGE_RETURN_POSTPONE, in which case subclasses would just skip their action and return to the caller. Later, sriov_params_cb() would directly call nm_device_activate_schedule_stage2_device_config(), and thus act_stage1_prepare() was never executed for the subclass. That is wrong. First, I don't think it is good to let subclasses decide whether to call a parents implementation (and when). It just causes ambiguity. In the best case we do it always in the same order, in the worst case we call the parent at the wrong time or never. Instead, we want to initialize SR-IOV always and early in stage1, so we should just do it directly from activate_stage1_device_prepare(). Now NMDevice's act_stage1_prepare() does nothing. The bigger problem is that when a device wants to resume a stage that it previously postponed, that it would schedule the next stage! Instead, it should schedule the same stage again instead. That allows to postpone the completion of a stage for multiple reasons, and each call to a certain stage merely notifies that something changed and we need to check whether we can now complete the stage. For that to work, stages must become re-entrant. That means we need to remember whether an action that we care about needs to be started, is pending or already completed. Compare this to nm_device_activate_schedule_stage3_ip_config_start(), which checks whether firewall is configured. That is likewise the wrong approach. Callers that were in stage2 and postponed stage2, and later would schedule stage3 when they are ready. Then nm_device_activate_schedule_stage3_ip_config_start() would check whether firewall is also ready, and do nothing if that's not the case (relying that when the firewall code completes to call nm_device_activate_schedule_stage3_ip_config_start().
Diffstat (limited to 'src/settings/nm-settings-connection.c')
0 files changed, 0 insertions, 0 deletions