diff options
author | Thomas Haller <thaller@redhat.com> | 2017-11-07 10:48:55 +0100 |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2017-11-08 12:35:10 +0100 |
commit | f0731dc716f08d1187ff2c936a1fee0e8c4ab92f (patch) | |
tree | 05276ada369d166bd0017c9fb4e334aa38f9c771 /src/devices/ovs | |
parent | f7e72d9d702ea78fe04b1a9000727da76a31b71b (diff) | |
download | NetworkManager-f0731dc716f08d1187ff2c936a1fee0e8c4ab92f.tar.gz |
device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum
The flags allow for more then two reasons. Currently the only reasons
for allowing or disallowing autoconnect are "user" and "intern".
It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative
meaning. So
nm_device_set_autoconnect_intern (device, FALSE);
gets replaced by
nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN);
and so on.
However, it's chosen this way, because autoconnect shall be allowed,
unless any blocked-reason is set. That is, to check whether autoconnect
is allowed, we do
if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL))
The alternative check would be
if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL)
which seems odd too.
So, add the inverse flags to block autoconnect.
Beside refactoring and inverting the meaning of the autoconnect
settings, there is no change in behavior.
(cherry picked from commit 5279ab5be6326b911682e53d8c29d20a501d61b8)
Diffstat (limited to 'src/devices/ovs')
0 files changed, 0 insertions, 0 deletions