We have NMMetaSettingType enum, which is an enum of all setting types.
We also have an efficient way to get the enum (and its NMMetaSettingInfo)
from an NMSetting, setting-name and GType.
No longer maintain the vtable for keyfile by "setting-name". Instead,
index it by NMMetaSettingType enum.
That way, we get efficient lookup, and don't need to duplicate the
functionality of finding the vtable entry for a setting.
nm_meta_setting_infos_by_name() did a naive search by name by
iterating over all 42 setting types.
Reorder nm_meta_setting_infos array, and use binary search instead.
Previously, each (non abstract) NMSetting class had to register
its name and priority via _nm_register_setting().
Note, that libnm-core.la already links against "nm-meta-setting.c",
which also redundantly keeps track of the settings name and gtype
as well.
Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta
data.
The goal is to get rid of private data structures that track
meta data about NMSetting classes. In this case, "registered_settings"
hash. Instead, we should have one place where all this meta data
is tracked. This was, it is also accessible as internal API,
which can be useful (for keyfile).
Note that NMSettingClass has some overlap with NMMetaSettingInfo.
One difference is, that NMMetaSettingInfo is const, while NMSettingClass
is only initialized during the class_init() method. Appart from that,
it's mostly a matter of taste, whether we attach meta data to
NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed
by NMMetaSettingType.
Note, that previously, _nm_register_setting() was private API. That
means, no user could subclass a functioning NMSetting instance. The same
is still true: NMMetaSettingInfo is internal API and users cannot access
it to create their own NMSetting subclasses. But that is almost desired.
libnm is not designed, to be extensible via subclassing, nor is it
clear why that would be a useful thing to do. One day, we should remove
the NMSetting and NMSettingClass definitions from public headers. Their
only use is subclassing the types, which however does not work.
While libnm-core was linking already against nm-meta-setting.c,
nm_meta_setting_infos was unreferenced. So, this change increases
the binary size of libnm and NetworkManager (1032 bytes). Note however
that roughly the same information was previously allocated at runtime.
Not all properties that we want to handle in nmcli are actual GObject
properties. For the moment that was the case, but that's about to change.
This is a change in behavior with respect of the order in which
properties are reported. For example, print_setting_description()
now prints the property descriptions in a different order. However,
one might argue that this order makes more sense because:
- it's the same order as properties are listed in
"nm-meta-setting-desc.c". At that place, we have explict
control over the order and set it intentionally to suite
our needs best. The order of the GObject properties is
much less well defined.
- the order from "nm-meta-setting-desc.c" is used at several other
places. So, it makes sense to use the same order everywhere.
- Don't use @parent_class name. This local variable (and @object_class) is
the class instance up-cast to the pointer types of the parents. The point
here is not that it is the direct parent. The point is, that it's the
NMSettingClass type.
Also, it can only be used inconsistently, in face of NMSettingIP4Config,
who's parent type is NMSettingIPConfig. Clearly, inside
nm-setting-ip4-config.c we wouldn't want to use the "parent_class"
name. Consistently rename @parent_class to @setting_class.
- Also rename the pointer to the own class to @klass. "setting_class" is also the
wrong name for that, because the right name would be something like
"setting_6lowpan_class".
However, "klass" is preferred over the latter, because we commonly create new
GObject implementations by copying an existing one. Generic names like "klass"
and "self" inside a type implementation make that simpler.
- drop useless comments like
/* virtual functions */
/* Properties */
It's better to logically and visually structure the code, and avoid trival
remarks about that. They only end up being used inconsistently. If you
even need a stronger visual separator, then an 80 char /****/ line
should be preferred.
Properties that are backed by a GObject property are fundamentally
different.
I think it's clearer to rework the check, to first check whether
we have a param_spec, and then implement different checks.
Parsing can be complicated enough. It's simpler to just work
top-to-bottom, without calling various helper functions. This was,
you can see all the code in one place, without need to jump to
the helper function to see what it is doing.
In general, a static function that is only called once, does sometimes
not simplify but obfuscate the code.
The tests already honored the environment variable $NMTST_IFCFG_RH_UPDATE_EXPECTED
to indicate that the .cexpected files should be written by the tests.
However, in the meantime, we instead use NM_TEST_REGENERATE=1 at various
places for this purpose. Honor that flag as well.
When assuming existing connections, allow the same connection to be
activated on a different device if the connection is multi-connect
capable. Otherwise, when a connection is active on multiple devices
and NM is restarted, we assume only the first instance, and create
in-memory connections for others.
In general, a activatable connection is one that is currently not
active, or supports to be activatable multiple times according to
multi-connect setting. In addition, during autoconnect, a profile
which is marked as multi-connect=manual-multiple will not be avalable.
Hence, add an argument "for_auto_activation".
The code is mostly unused but will be used next (except for connections,
which set connection.multi-connect=multiple).
Add a new option that allows to activate a profile multiple times
(at the same time). Previoulsy, all profiles were implicitly
NM_SETTING_CONNECTION_MULTI_CONNECT_SINGLE, meaning, that activating
a profile that is already active will deactivate it first.
This will make more sense, as we also add more match-options how
profiles can be restricted to particular devices. We already have
connection.type, connection.interface-name, and (ethernet|wifi).mac-address
to restrict a profile to particular devices. For example, it is however
not possible to specify a wildcard like "eth*" to match a profile to
a set of devices by interface-name. That is another missing feature,
and once we extend the matching capabilities, it makes more sense to
activate a profile multiple times.
See also https://bugzilla.redhat.com/show_bug.cgi?id=997998, which
previously changed that a connection is restricted to a single activation
at a time. This work relaxes that again.
This only adds the new property, it is not used nor implemented yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1555012
For dynamic IP methods (DHCP, IPv4LL, WWAN) the route metric is set at
activation/renewal time using the value from static configuration. To
support runtime change we need to update the dynamic configuration in
place and tell the DHCP client the new value to use for future
renewals.
https://bugzilla.redhat.com/show_bug.cgi?id=1528071
Some warnings depends on others: -Wformat-security won't work without
-Wformat. With -Wall we're confident enough that we have important
warnings enabled and in any case we're going to enable it anyway.
https://github.com/NetworkManager/NetworkManager/pull/175
g-ir-scanner uses distutils that have an unfortunate misfeature of
inheriting the compiler flags it itself was built with.
This includes the hardening flags that don't work with without
redhat-rpm-build and break with clang every full moon.
A configure check makes it clear about what went wrong in case
introspection is desired, otherwise turns it off.
(Taken from network-manager commit 678890ed0347849990787e8893122a39f95cb708)
This is a mere debugging convenience thing: e.g. if you run, but want to
check whether nm-applet or nmcli agent works fine, it's convenient that
the agent you run later gets a chance to deal with the secrets requests
first.
Is seems to do the job and is simpler that adding some more complicated
policy (e.g. introducing priorities or something).
https://github.com/NetworkManager/NetworkManager/pull/174
NM_SETTING_NAME is a special property that only has relevance
to libnm. It is inherited by all NMSetting instances. It is
read-only, and it has no corresponding value on D-Bus or nmcli.
Skip it during generate-setting-docs.py.
This also drops it from `man nm-settings`, where it doesn't belong.
Update the device state file every time the device is connected,
disconnected, or becomes unmanaged. In this way, NM becomes more
robust against crashes or forced terminations because it can resume
the previous device state seamlessly.
Rename nm_manager_write_device_state() to
nm_manager_write_device_state_all(), and split out the code to write a
single device state to a new function.
