nm-device now applies ethtool coalesce settings during stage 2 "device
config" of the connection activation.
Coalesce settings will be then restored (according to what the state
was before the connection got activated on the device) when the
connection is deactivated during the device cleanup.
One thing to be noted is that unset coalesce settings (in the profile)
will not be touched at all by NetworkManager so that if the NIC driver
sets some default values these will be preserved unless specifically
overridden by the connection profile.
https://bugzilla.redhat.com/show_bug.cgi?id=1614700
NM_SET_OUT() macro already has an "if" condition to only do
anything if the output pointer is not NULL.
As such, we don't need to check first. In practice, this only reorders
the checks, which the compiler may anyway do.
Note that above the checks are still relevant, because we want to
avoid the more expensive parsing, if we don't care about the result.
- nm_streq() is easier to read.
- NM_STR_HAS_PREFIX() works only with string literals, and gets
inlined up to one strncmp() call. There is no need to call glib,
to determine strlen(prefix) (that we already know), and then to
call strncmp().
On Fedora/RHEL, the default for main.plugins is "ifcfg-rh". You would
expect that a single configuration file
[main]
plugins-=ifcfg-rh
would result in an empty list of plugins (which subsequently gets
completed with "keyfile").
That didn't happen due to a bug. Fix it.
lgtm.com warns:
int nm_owned:3;
>> Bit field nm_owned of type int should have explicitly unsigned integral, explicitly signed integral, or enumeration type.
So make it a NMTernary instead. It's nicer anyway.
lgtm.com flags this. The check was there to be better safe than sorry.
Also, it seems better to have code that shows what happens instead
of a verbose code comment (or no comment at all). Anyway, avoid the
false positive.
Reported by coverity:
>>> CID 210222: Null pointer dereferences (NULL_RETURNS)
>>> Dereferencing a pointer that might be "NULL" "f" when calling
"fseek".
Fixes: ac5206aa9c ('2007-11-21')
If the driver is unknown, that doesn't necessarily mean that the match
passes. Instead, the match passes if there is no positive match that
asks for the driver name.
%NULL means that the string is unknown. The pattern should still match
if there are no positive matches that want to match against the string.
For example, the nm_device_get_driver() might return NULL. If we have
a match.driver setting, we still need to handle that somehow that it
makes sense.
