diff options
author | Thomas Haller <thaller@redhat.com> | 2019-08-21 14:30:34 +0200 |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2019-08-28 16:27:00 +0200 |
commit | cca0c2b56a4c637d8fc222353126b6f46187ba53 (patch) | |
tree | 79f326a67fdcc1b2bb6022780e3538fcfa111691 /src/settings/nm-settings-connection.c | |
parent | c3d41fa4529ec9c9e266d117cc5b8ec4e2d917b8 (diff) | |
download | NetworkManager-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