Some targets are missing dependencies on some generated sources in
the meson port. These makes the build to fail due to missing source
files on a highly parallelized build.
These dependencies have been resolved by taking advantage of meson's
internal dependencies which can be used to pass source files,
include directories, libraries and compiler flags.
One of such internal dependencies called `core_dep` was already in
use. However, in order to avoid any confusion with another new
internal dependency called `nm_core_dep`, which is used to include
directories and source files from the `libnm-core` directory, the
`core_dep` dependency has been renamed to `nm_dep`.
These changes have allowed minimizing the build details which are
inherited by using those dependencies. The parallelized build has
also been improved.
Tests are commonly created via copy&paste. Hence, it's
better to express a certain concept explicitly via a function
or macro. This way, the implementation of the concept can be
adjusted at one place, without requiring to change all the callers.
Also, the macro is shorter, and brevity is better for tests
so it's easier to understand what the test does. Without being
bothered by noise from the redundant information.
Also, the macro knows better which message to expect. For example,
messages inside "src" are prepended by nm-logging.c with a level
and a timestamp. The expect macro is aware of that and tests for it
#define NMTST_EXPECT_NM_ERROR(msg) NMTST_EXPECT_NM (G_LOG_LEVEL_MESSAGE, "*<error> [*] "msg)
This again allows the caller to ignore this prefix, but still assert
more strictly.
The logging macros already prepend a "config: " prefix. Don't
repeat that in the message, otherwise we get
config: config: signal SIGHUP (no changes from disk)
Now:
config: signal: SIGHUP (no changes from disk)
Also, ifnet plugin would read the configuration value, which is just wrong
because:
- the configuration might not be set and ifnet would fail to fallback
to the compile time default.
- the configuration only is in effect if the plugin is also available.
Otherwise, we fallback to the next plugin.
Only the dhcp-manager knows which DHCP plugin is in use.
Instead of having the caller do the fallback to the compile time default
plugins, let it be handled by nm_config_get_plugins().
The knowledge of fallback to a compile time default (and how to do that
properly) should be inside NMConfig/NMConfigData alone.
Also, as this function is only called once, let NMConfig not cache
the string list but create it once as needed.
Keep the include paths clean and separate. We use directories to group source
files together. That makes sense (I guess), but then we should use this
grouping also when including files. Thus require to #include files with their
path relative to "src/".
Also, we build various artifacts from the "src/" tree. Instead of having
individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be
unified. Previously, the CFLAGS for each artifact differ and are inconsistent
in which paths they add to the search path. Fix the inconsistency by just
don't add the paths at all.
- use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere.
- reorder statements, to have GObject related functions (init, dispose,
constructed) at the bottom of each file and in a consistent order w.r.t.
each other.
- unify whitespaces in signal and properties declarations.
- use NM_GOBJECT_PROPERTIES_DEFINE() and _notify()
- drop unused signal slots in class structures
- drop unused header files for device factories
- don't include "nm-default.h" in header files. Every source file must
include as first header "nm-default.h", thus our headers get the
default include already implicitly.
- we don't support compiling NetworkManager itself with a C++ compiler. Remove
G_BEGIN_DECLS/G_END_DECLS from internal headers. We do however support
users of libnm to use C++, thus they stay in public headers.
(cherry picked from commit f19aff8909)
Using the current, possibly non-permanent MAC address doesn't really
make sense.
Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt
to the bdaddr. That is wrong, because bdaddr should not be the current
address, but the permanent one.
hw-addr is a constuct-only property. We should not do complex stuff in the property
setter before the object is sufficiently initialized. For example, the logging
macros access nm_device_get_iface(), which might be unset at that early
point.
Instead, initialize hw_addr and hw_addr_len later, at the end of the constructor()
function.
Also, ensure that @hw_addr_len is zero iff @hw_addr is unset.
Also, ensure that we always log a message when changing/setting the
hardware address -- except when clearing it during unrealize. It's
implicit that unrealize clears the hardware address.
Also, give all related logging messages a "hw-addr:" prefix.
For the most part, this patch just renames some change-flags, but
doesn't change much about them. The new name should better express
what they are.
A config-change signal can be emitted for different reasons:
when we receive a signal (SIGHUP, SIGUSR1, SIGUSR2) or for internal
reasons like resetting of no-auto-default or setting internal
values.
Depending on the reason, we want to perform different actions.
For example:
- we reload the configuration from disk on SIGHUP, but not for
SIGUSR1.
- For SIGUSR1 and SIGHUP, we want to update-dns, but not for SIGUSR2.
Another part of the change-flags encodes which part of the configuration
actually changed. Often, these parts can only change when re-reading
from disk (e.g. a SIGUSR1 will not change any configuration inside
NMConfig).
Later, we will have more causes, and accordingly more fine-grained
effects of what should be done on reload.
A large part of "nm-test-utils.h" is only relevant for tests inside "src/"
directory, as they are helpers related to NetworkManager core part.
Split this part out of "nm-test-utils.h" header.
Valgrind doesn't like it, so don't use g_file_copy().
==10410== Syscall param ioctl(generic) points to unaddressable byte(s)
==10410== at 0x82E1707: ioctl (syscall-template.S:84)
==10410== by 0x7712E71: btrfs_reflink_with_progress (gfile.c:3012)
==10410== by 0x7712E71: file_copy_fallback (gfile.c:3186)
==10410== by 0x7712E71: g_file_copy (gfile.c:3394)
==10410== by 0x1350CA: test_config_state_file (test-config.c:948)
==10410== by 0x7D0845A: test_case_run (gtestutils.c:2158)
==10410== by 0x7D0845A: g_test_run_suite_internal (gtestutils.c:2241)
==10410== by 0x7D08622: g_test_run_suite_internal (gtestutils.c:2253)
==10410== by 0x7D0882D: g_test_run_suite (gtestutils.c:2328)
==10410== by 0x7D08850: g_test_run (gtestutils.c:1596)
==10410== by 0x12EFA4: main (test-config.c:1032)
==10410== Address 0x9 is not stack'd, malloc'd or (recently) free'd
==10410==
Fixes: e3a30665d7
After all, this state is stored persistently to /var/lib/NetworkManager,
and not to volatile storage in /var/run. Hence the name is better.
It's also shorter, so rename it.
The commit is mostly trivial, including update of code comments
and logging messages.
Fixes: 1b43c880ba
For internal compilation we want to be able to use deprecated
API without warnings.
Define the version min/max macros to effectively disable deprecation
warnings.
However, don't do it via CFLAGS option in the makefiles, instead hack it
to "nm-default.h". After all, *every* source file that is for internal
compilation needs to include this header as first.
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
Up to now, the "include" directory contained (only) header files that were
used project-wide by libs, core, clients, et al.
Since the directory now also contains a non-header file, the "include"
name is misleading. Instead of adding yet another directory that is
project-wide, with non-header-only content, rename the "include"
directory to "shared".
No longer support disabling the global-dns configuration via the
"enable" option.
Instead, the user can put the entire dns-configuration in one separate
snippet, and disable it altogether with ".config.enable".
Support a new configuration option
[.config]
enable=<ENABLED>
for configuration snippets.
This new [.config] section is only relevant within the snippet itself
and it is not merged into the combined configuration.
Currently only the "enable" key is supported. If the "enable" key is
missing, it obviously defaults to being enabled. It allows snippets
to be skipped from loading. The main configuration "NetworkManager.conf"
cannot be skipped.
<ENABLED> can be a boolean value (false), to skip a configuration
snippet from loading.
It can also be a string to match against the NetworkManager version,
like "enable=nm-version-min:1.1,nm-version-min:1.0.6"
There are several motivations for this:
- the user can disable an entire configuration snippet by toggeling
one entry.
This generalizes the functionality of the global-dns.enable
setting, but in a way that applies to configuration on a per-file
basis.
- for developing, we often switch between different versions of
NetworkManager. Thus, we might want to use different configuration.
E.g. before global-dns options, I want to use "dns=none" and manage
resolv.conf myself. Now, I can use global-dns setting to do that.
That can be achieved with something like the following (not exactly,
it's an example only):
[.config]
enable=nm-version-min:1.1
[main]
dns=default
[global-dns-domain-*]
nameserver=127.0.0.1
Arguably, this would be more awesome, if we would bump our micro devel
version (1.1.0) more often while developing 1.2.0 (*hint*).
- in principle, packages could drop configuration snippets and enable
them based on the NetworkManager version.
- with the "env:" spec, you can enable/disable snippets by configuring
an environment variable. Again, useful for testing and developing.
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
There seems to be a bug in glib/ffi that hits on s390x/ppc64 architecture.
It causes @changes in nm-dns-manager.c:config_changed_cb() to be NONE,
although it is clearly set (see the related bug rh #1260577 for glib).
Workaround this, by making the argument type a plain guint.
Note that the ill behavior is caught by test_config_signal() in
"src/tests/config/test-config.c".
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1062301
The config-tests contain a NMTestDevice which derives from NMDevice.
However, for testing, it just skips the constructor and destructor of
NMDevice. This caused also the destructors of NMExportedObject to be skipped
and thus valgrind complained about leaked memory.
Fixes: 6fcc1deee0
Port remaining bits to gdbus and remove stray dbus-glib references
Drop the dbus-glib version check from configure, since nothing depends
on new dbus-glib any more.
Move nm-dbus-glib-types.h and nm-gvaluearray-compat.h from include/ to
libnm-util/ since they are now only used by libnm-util and libnm-glib.
This internal header file should be included by our internal source
code files and header files. It includes in one place other headers
that constitute to a minimal set of required headers. Most notably
this is <glib.h> and our "nm-glib.h" header.
Note that public header files and example source code cannot include
this file as "nm-default.h" is internal only.
Our gdbus generated types use the same names as their corresponding
"real" types, but with "NM" changed to "NMDBus".
Unfortunately, that means that introspection/nmdbus-manager.c (the
generated type for src/nm-manager.c) uses the same type name as the
entirely unrelated src/nm-dbus-manager.c.
Fix this by removing the "d" from src/nm-dbus-manager.c. (We could
rename the generated type instead, but then it becomes inconsistent
with all the other generated types, and we're already using it as
"NMDBusManager" in libnm/nm-manager.c.)
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
We already support setting configuration values, either:
(1) set any internal section, i.e. groups starting with [.intern*].
Those values don't ever interfere with that the user can
configure.
(2) set individual properties that overwrite user configuration.
When doing that, we record the value from user configuration
and on load, we reject our internal overwrite if the user
configuration changed in the meantime.
This is done by storing the values with ".set." and ".was." prefixes.
Now add support for "atomic sections". In this case, certain groups
can be marked as "atomic". When writing to such sections, we overwrite
the entire user-provided setting.
We also record the values from user configuration, and reject our
internal value if we notice modifications. This basically extends
(2) from individual properties to the entire section.
Internal configuration is written as keyfile to
NMSTATEDIR"/NetworkManager-intern.conf"
Basically, the content of this file is merged with user
configuration from "NetworkManager.conf" files. After loading
the configuration, NMConfig exposes a merged view of user-provided
settings and internal overwrites.
All sections/groups named [.intern*] are reserved for internal
configuration values. They can be written by API, but are ignored
when the user sets them via "NetworkManager.conf". For these
internal sections, no conflicts can arise.
We can also overwrite individual properties from user configuration.
In this case, we store the value we want to set, but also remember
the value that the user configuration had, at the time of setting.
If on a later reload the user configuration changed, we ignore our
internal value -- as we assume that the user modified the value
afterwards.
We can also hide/delete value from user configuration.
This works on a per-setting basis.
This allows packages to install their configuration snippets to
"/usr/", which is a better place for system-provided configuration
files then "/etc".
"/usr/lib/NetworkManager/conf.d/" is read first, so that the values
in /etc have higher priority.
In general, we want to move system-provided configuration away from
/etc, so that a user can do a "factory-reset" by purging /etc.
https://bugzilla.gnome.org/show_bug.cgi?id=738853
