Changes:
- match_device_s390_subchannels_parse() should accept un-initialized
arguments a,b,c, as they are striclty output arguments (without
transfering ownership).
- the output arguments should be set if (and only if) the function
succeeds. That is, move assigning the output arguments to the end.
- increase the BUFSIZE. It's unclear why choosing 10. Probably that
was already sufficient as a subchannel looks like
"0.0.f5f0,0.0.f5f1,0.0.f5f2". Still, increase it to be ample.
If we want to restrict the parsing based on the lenght of the input,
that should be done explicitly (but that seems not desirable).
- use _nm_utils_ascii_str_to_int64() which checks that the range
of the values fits in guint32.
It seems wrong that match_device_s390_subchannels_eval() only compares
the first of up to three subchannels. But leave it as is for now.
(cherry picked from commit 419151a19e)
Changes:
- match_device_s390_subchannels_parse() should accept un-initialized
arguments a,b,c, as they are striclty output arguments (without
transfering ownership).
- the output arguments should be set if (and only if) the function
succeeds. That is, move assigning the output arguments to the end.
- increase the BUFSIZE. It's unclear why choosing 10. Probably that
was already sufficient as a subchannel looks like
"0.0.f5f0,0.0.f5f1,0.0.f5f2". Still, increase it to be ample.
If we want to restrict the parsing based on the lenght of the input,
that should be done explicitly (but that seems not desirable).
- use _nm_utils_ascii_str_to_int64() which checks that the range
of the values fits in guint32.
It seems wrong that match_device_s390_subchannels_eval() only compares
the first of up to three subchannels. But leave it as is for now.
If a slave device activates, we should keep the master up even though it
was taken over before.
This fixes an issue, where a single slave to a master would be
reactivated after a daemon restart. The daemon restart would cause the
master to be treated externally created (would go unmanaged when all the
slaves are gone) while the reactivation would leave the master without
slaves for a while.
The public property NM_DEVICE_ACTIVATION_REQUEST exposes the exported
D-Bus path. So, it's not sufficient to emit property changed signals
when changing the priv->act_request pointer, we must also react on
exporting/unexporting.
It's not clear whether this fixes an actual bug. Maybe, we never
export/unexport priv->act_request while the device tracks it.
But the code is pretty hard to follow and it's hard to verify
whether this is the case.
By hooking up to "notify::path", we can easily verify that such
a situtation cannot arise.
For better or worse, nm_exported_object_unexport() asserts that the
object is currently exported.
It's not clear that an active connection at this place is always
exported.
Fixes: f0e3dfdace
(cherry picked from commit c8a649b3de)
The active connection has an immutable connection property, but is
cleaned asynchronously by the manager after its settings connection is
done. Fine, let's remove it from the bus first though, so that we don't
hang there with a dangling object path.
(cherry picked from commit f0e3dfdace)
For better or worse, nm_exported_object_unexport() asserts that the
object is currently exported.
It's not clear that an active connection at this place is always
exported.
Fixes: f0e3dfdace
The active connection has an immutable connection property, but is
cleaned asynchronously by the manager after its settings connection is
done. Fine, let's remove it from the bus first though, so that we don't
hang there with a dangling object path.
When searching for "*", we still need to check for higher priority
"except:" matches. But don't duplicate the search loop and just
proceed with the regular searched.
It already has the "if (!except && match == NM_MATCH_SPEC_MATCH)" which
short-cuts the search.
(cherry picked from commit 9fff9f501a)
Instead of passing on invdividual arguments for the match, create
a MatchDeviceData structure and pass it on.
This reduces the number of arguments and extending it later should
be easier. Also, lazily parse the hardware address as needed.
(cherry picked from commit b0aaff86b6)
When searching for "*", we still need to check for higher priority
"except:" matches. But don't duplicate the search loop and just
proceed with the regular searched.
It already has the "if (!except && match == NM_MATCH_SPEC_MATCH)" which
short-cuts the search.
Instead of passing on invdividual arguments for the match, create
a MatchDeviceData structure and pass it on.
This reduces the number of arguments and extending it later should
be easier. Also, lazily parse the hardware address as needed.
* all getter/setter/describe, ... functions grouped according to properties
* sort the settings groups alphabetically
(cherry picked from commit 418733f2c1)
Previously, we would have different functions like
- nm_match_spec_device_type()
- nm_match_spec_hwaddr()
- nm_match_spec_s390_subchannels()
- nm_match_spec_interface_name()
which all would handle one type of match-spec.
So, to get the overall result whether the arguments
match or not, nm_device_spec_match_list() had to stich
them together and iterate the list multiple times.
Refactor the code to have one nm_match_spec_device()
function that gets all relevant paramters.
The upside is:
- the logic how to evaluate the match-spec is all at one place
(match_device_eval()) instead of spread over multiple
functions.
- It requires iterating the list at most twice. Twice, because
we do a fast pre-search for "*".
One downside could be, that we have to pass all 4 arguments
for the evaluation, even if the might no be needed. That is,
because "nm-core-utils.c" shall be independend from NMDevice, it
cannot receive a device instance to get the parameters as needed.
As we would add new match-types, the argument list would grow.
However, all arguments are cached and fetching them from the
device's private data is very cheap.
(cherry picked from commit b957403efd)
Previously, we would have different functions like
- nm_match_spec_device_type()
- nm_match_spec_hwaddr()
- nm_match_spec_s390_subchannels()
- nm_match_spec_interface_name()
which all would handle one type of match-spec.
So, to get the overall result whether the arguments
match or not, nm_device_spec_match_list() had to stich
them together and iterate the list multiple times.
Refactor the code to have one nm_match_spec_device()
function that gets all relevant paramters.
The upside is:
- the logic how to evaluate the match-spec is all at one place
(match_device_eval()) instead of spread over multiple
functions.
- It requires iterating the list at most twice. Twice, because
we do a fast pre-search for "*".
One downside could be, that we have to pass all 4 arguments
for the evaluation, even if the might no be needed. That is,
because "nm-core-utils.c" shall be independend from NMDevice, it
cannot receive a device instance to get the parameters as needed.
As we would add new match-types, the argument list would grow.
However, all arguments are cached and fetching them from the
device's private data is very cheap.
After commit 553717bb1c ("device: don't set ip4_state=IP_FAIL for
ipv4.method=disabled"), we commit an empty IPv4 configuration when
IPv4 is disabled. This means that it's not necessary anymore to call
_commit_mtu() because the MTU will be set in
ip4_config_merge_and_apply().
(cherry picked from commit 714b18dcf7)
After commit 22e8af6242 ("device: set a per-device default MTU on
activation") we explicitly set the VLAN MTU to 1500 if not overridden
by user settings. This has the advantage that the MTU is set to a
predictable value, while before it could have different values
depending on when the interface was created (for example, the
interface would get a 1500 MTU if created during boot, or would
inherit the parent's MTU if activated manually).
However, a better default value is the MTU of the parent interface
which is in most cases what the user wants. This value was the default
before commit 22e8af6242 for manually activated connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1414186
(cherry picked from commit 7dde8d8106)
After commit 22e8af6242 ("device: set a per-device default MTU on
activation") we explicitly set the VLAN MTU to 1500 if not overridden
by user settings. This has the advantage that the MTU is set to a
predictable value, while before it could have different values
depending on when the interface was created (for example, the
interface would get a 1500 MTU if created during boot, or would
inherit the parent's MTU if activated manually).
However, a better default value is the MTU of the parent interface
which is in most cases what the user wants. This value was the default
before commit 22e8af6242 for manually activated connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1414186
After commit 553717bb1c ("device: don't set ip4_state=IP_FAIL for
ipv4.method=disabled"), we commit an empty IPv4 configuration when
IPv4 is disabled. This means that it's not necessary anymore to call
_commit_mtu() because the MTU will be set in
ip4_config_merge_and_apply().
