NMPObject is a simple "object" implemenation around NMPlatformObject.
They are ref-counted and have a class-pointer. Several basic functions
like equality, hash, to-string are implemented.
NMPCache is can be used to store the NMPObject. Objects are indexed
via their primary id, but there is also multi-lookup via NMCacheId
and NMMultiIndex.
Part of the implementation is inside "nm-linux-platform.c",
because it depends on utility functions from there.
A class to do efficient lookup for multiple values based on a key.
The values are opaque pointers (void*). These values can be
associated with keys. The keys are an opaque type NMMultiIndexId
with arbitrary hash/equal functions.
Think of the keys being a set of buckets. A value can be associated with multiple
keys, just like with a regular GHashTable (i.e. it can be in multiple buckets).
But one key can also be associated with multiple values (i.e. one bucket can contain
multiple values). Hence the name "multi".
One bucket can only either contain a value or not. It cannot contain the same
value multiple times.
This is implemented as a hash of hashes with the outer keys being
NMMultiIndexId. The inner hashes are the "buckets".
This class will be used as an efficient lookup index to find all values
that belong to a certain key (bucket). Later we will ask for example
"Which IP4-Addresses are associated with a certain ifindex" and
efficiently retrieve the cached result list.
NMRefString is a simple, refcounted, immutable string. Increasing/decreasing
the refcount does not affect const-ness.
It can be used just like a regular 'const char *' pointer. The only
difference is that you need special alloc/free functions.
Cache the scope as part of the NMPlatformIP4Route and
no longer read it from libnl object when needed. Later
there will be no more libnl objects around, and we need
to scope when deleting an IPv4 route.
- move all hostname-related functions from plugins to the core
- allow to specify the method used to load and store the hostname at
build time
- add hostnamed support
- remove unused setting plugins
https://bugzilla.gnome.org/show_bug.cgi?id=740409
The 'example' settings plugin is (obviously) unused, but it is also
badly maintained and no longer best-practice in several ways:
- it directly reads "NetworkManager.conf" instead of using NMConfig.
- it parses device specs itself, instead of using
nm_match_spec_split().
- read_connections() doesn't ensure that loading a file
does not replace a previously loaded one (due to conflicting
UUID). In general the example doesn't show/handle the complexity
of potential UUID conflicts.
Instead of fixing these issues it is better to ensure our main plugin
('keyfile') corresponds to current best practices. Should we ever add a
new pluginww, 'keyfile' should be the example.
Instead of parsing "/etc/NM/NetworkManager.conf" in keyfile plugin itself,
use NMConfig. Parsing it outside of NMConfig API has the significant disadvantage
of not considering files under "conf.d/".
This also has a behavioral change: keyfile no longer monitors
"NetworkManager.conf" file for changes, but instead only reacts
on explict "config-changed" signals from NMConfig.
This previous behavior of picking up file changes without
user-interaction is anyway not what we want. NM should not react
on mere file changes, but only on explicit reload commands. And
even if we want to support it, file watching should be implemented
properly inside NMConfig, watching *all* relevant files.
This was the last out-of-api access to the configuration after
refactoring NMConfig. Now that keyfile plugin no longer writes
the hostname, we can get rid of this.
After the hostname functionality has been moved from plugins to core,
the ifcfg-suse plugin contains only boilerplate code with no actual
functionality.
Remove the plugin, mark it as deprecated in manual page and print a
warning when it is selected in configuration file.
When the systemd-hostnamed daemon is available, use it to read and
change the hostname.
Based on 'danw/wip/hostnamed' branch by Dan Winship <danw@redhat.com>
How to write and read the machine hostname is something that has been
handled until now by plugins; this is questionable since the method
using for storing the hostname should depend only on the distro used
and not on which plugins are enabled.
This commit moves all hostname-related functions from plugins to the
core and allows to specify the method used to load and store the
hostname at build time with the
--with-hostname-persist=default|suse|gentoo
configure option.
'default' method stores the hostname to /etc/hostname and monitors it
to detect runtime changes.
When the selected method is 'suse', the hostname gets read from and
written to /etc/HOSTNAME; the file /etc/sysconfig/network/dhcp is also
read to detect if the hostname is dynamic and thus invalid. Both files
are monitored for changes.
'gentoo' method relies on /etc/conf.d/hostname for storing the
hostname.
warning: function declaration isn’t a prototype [-Wstrict-prototypes]
In C function() and function(void) are two different prototypes (as opposed to
C++).
function() accepts an arbitrary number of arguments
function(void) accepts zero arguments
The metered property of a NMDevice that reaches the activated state is
copied from the active connection and if its value is 'unknown' some
heuristics are used to guess the actual value.
When the connection is torn down the metered property is reset to
'unknown'.
Some versions of Android's DHCP server send option 43 (Vendor specific
information) with value "ANDROID_METERED" in Wi-Fi hotspot mode.
Mark the NMIP4Config as metered when such option is received.
This adds support for DHCP option 43 (Vendor Specific Information) to
the internal DHCP client. The option carries an opaque object of n
octets, interpreted by vendor-specific code on the clients and
servers.
Some DHCP servers send specific options to give a hint that clients
should avoid unneeded data usage.
Add a metered flag to NMIP4Config to keep track of this information.
Add a 'metered' enum property to NMSettingConnection with possible
values: unknown,yes,no. The value indicates the presence of limitations
in the amount of traffic flowing through the connection.
