This speeds up the initial object tree load significantly. Also, it
reduces the object management complexity by shifting the duties to
GDBusObjectManager.
The lifetime of all NMObjects is now managed by the NMClient via the
object manager. The NMClient creates the NMObjects for GDBus objects,
triggers the initialization and serves as an object registry (replaces
the nm-cache).
The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the
object creation, removal and property changes. It takes care of the
property changes so that we don't have to and lets us always see a
consistent object state. Thus at the time we learn of a new object we
already know its properties.
The NMObject unfortunately can't be made synchronously initializable as
the NMRemoteConnection's settings are not managed with standard
o.fd.DBus Properties and ObjectManager APIs and thus are not known to
the ObjectManager. Thus most of the asynchronous object property
changing code in nm-object.c is preserved. The objects notify the
properties that reference them of their initialization in from their
init_finish() methods, thus the asynchronously created objects are not
allowed to fail creation (or the dependees would wait forever). Not a
problem -- if a connection can't get its Settings, it's either invisible
or being removed (presumably we'd learn of the removal from the object
manager soon).
The NMObjects can't be created by the object manager itself, since we
can't determine the resulting object type in proxy_type() yet (we can't
tell from the name and can't access the interface list). Therefore the
GDBusObject is coupled with a NMObject later on.
Lastly, now that all the objects are managed by the object manager, the
NMRemoteSettings and NMManager go away when the daemon is stopped. The
complexity of dealing with calls to NMClient that would require any of
the resources that these objects manage (connection or device lists,
etc.) had to be moved to NMClient. The bright side is that his allows
for removal all of the daemon presence tracking from NMObject.
We'll soon not only do the router discovery, but announce ourselves as a
reouter. "Neighbor discovery" sounds to be a more appropriate name for
the class than "Router discovery".
This is especially important because we don't support
line continuation. Thus, with
FOO='val
bar=3'
wrong line
F2=b
F3='b
XXX=adf'
XXX2=val2
'
we now write
FOO=
#NM: FOO='val
bar=
#NM: bar=3'
#NM: wrong line
F2=b
F3=
#NM: F3='b
XXX=
#NM: XXX=adf'
XXX2=val2
#NM: '
Basically, the writer will comment out any line that is
- not all-whitespace
- not a '#' comment (possibly proceeded by whitespace)
- not a valid variable assignment
This avoids that writer writes lines that are not understood by
ifcfg-rh plugin, but interferes with initscripts. E.g.
NAME=old-name'
rm -rf /
'
becomes
NAME=new-name
#NM: rm -rf /
#NM: '
make[2]: Entering directory './NetworkManager/NetworkManager-1.5.1/_build/sub'
VAPIGEN vapi/libnm.vapi
Gio-2.0.gir:62318.7-62318.47: warning: Virtual method `G.Resolver.lookup_service_async' conflicts with method of the same name
Gio-2.0.gir:64704.7-64704.31: warning: Signal `G.Settings.change_event' conflicts with method of the same name
Gio-2.0.gir:84847.7-84851.24: error: `UnixSocketAddress' already contains a definition for `abstract'
Gio-2.0.gir:84690.7-84692.21: note: previous definition of `abstract' was here
Makefile:16410: recipe for target 'vapi/libnm.vapi' failed
Fixes: 0fa2cf19e5
NetworkManager and nm-iface-helper compiled nm-dhcp-manager.c twice,
the latter with setting -DNM_DHCP_INTERNAL_ONLY to only enable the
internal plugin.
Change that to compile nm-dhcp-manager.c once for both users
by putting it into libNetworkManagerBase.
We only needed proper glib enum types for having properties
and signal arguments. These got all converted to plain int,
so no longer generate such an enum type.
There is an strange automake warning
Makefile.vapigen:49: warning: $(1) was already defined in condition TRUE, which includes condition ENABLE_VAPIGEN ...
Makefile.am:4: 'Makefile.vapigen' included from here
Makefile.glib:124: ... '$(1)' previously defined here
Makefile.am:1: 'Makefile.glib' included from here
when having
if ENABLE_VAPIGEN
include Makefile.vapigen
endif
That is worked around by removing the "if", which however
requires us to remove the error check in Makefile.vapigen.
Let's always build with tests, regardless of --enable-tests.
If the user builds with --enable-tests=no, we automake the tests
as check_PROGRAMS, which only compiles the tests during `make check`.
Otherwise, we automake them as noinst_PROGRAMS, which builds the
tests regularly as a normal build.
This way, a user who doesn't want to build the tests regularly,
still can build and run them via `make check`.
Had to rename "nm-enum-types.h" because it works badly with
"libnm/nm-enum-types.h". Maybe I could fix that differently,
but duplicate names is anyway error prone.
Note that "nm-core-enum-types.h" is already taken too, so
"nm-src-enum-types.h" it is.
Originally, the "callouts" directory contained various programs
that NetworkManager would call, for example the dhcp helper.
For a while, it only contains nm-dispatcher. Thus rename the directory
to indicate that it's for dispatcher.
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".
Add --without-libnm-glib, for people who don't want to build the
legacy client libraries. When building with this option, dbus-glib and
libdbus are not required.
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.
It seems like a poor default for various downstream toolchains. We can't
anticipate the compiler warnings for future compiler versions and older
ones are prone to false positives. Also, older gdbus-codegen is known
to generate code that triggers compiler warnings.
Let's keep it enabled for maintainer builds and distcheck so that we're
sure a tool chain that builds releases without warnings exists.
Port libnm-core/libnm to GDBus.
The NetworkManager daemon continues to use dbus-glib; the
previously-added connection hash/variant conversion methods are now
moved to NetworkManagerUtils (along with a few other utilities that
are now only needed by the daemon code).
This fixes up the code from the previous "clean" import, and adds
build infrastructure.
[There are two slightly orthogonal sets of changes in this patch.
First, the files added in the previous commit were modified as followed:
# Replace internal references to "libnm-util" and "libnm-glib" with "libnm"
perl -pi -e 's/libnm-(util|glib)/libnm/;' libnm-core/*.[ch] libnm-core/tests/*.[ch] libnm/*.[ch] libnm/tests/*.[ch]
# Fix includes of the enum-types files
perl -pi -e 's/nm-utils-enum-types/nm-core-enum-types/;' libnm-core/*.[ch] libnm-core/tests/*.[ch] libnm/*.[ch] libnm/tests/*.[ch]
perl -pi -e 's/nm-glib-enum-types/nm-enum-types/;' libnm/*.[ch] libnm/tests/*.[ch]
# Fix some python example code
perl -pi -e 's/import NMClient/import NM/;' -e 's/NMClient.Client\(\)/NM.Client()/;' libnm/nm-client.c
Then, the build infrastructure was added (without further modifying
any existing files in libnm-core or libnm.)
Note: to regenerate libnm.ver after rebase:
(head -2 libnm-util/libnm-util.ver; (grep -h '\s'nm_ libnm-util/libnm-util.ver libnm-glib/libnm-glib.ver | env LANG=C sort); tail -3 libnm-util/libnm-util.ver) > libnm/libnm.ver
]
The remaining contents of the test/ directory are:
- 2 python example programs that aren't as good as the ones in examples/
- a test of the deprecated libnm_glib API which isn't as good as the one
in libnm-glib/
- A DHCP-related test program that hasn't been relevant since 2005
Let's just kill it all
Create a new clients/ subdirectory at the top level, and move cli/ and
tui/ into it, as well as nm-online.c (which was previously in test/,
which made no sense).
cli/ was split into two subdirectories, src/ and completion/. While
this does simplify things (given that the completion file and the
binary both need to be named "nmcli"), it bloats the source tree, and
we can work around it by just renaming the completion file at install
time. Then we can combine the two directories into one and just have
it all under clients/cli/.
Certain build configurations (like --enable-gtk-doc
--disable-introspection) were broken with respect to nm-setting-docs.
Fix this. Also, we don't require just gobject-introspection, we need
pygobject specifically as well.
Add generate-setting-docs.py, based on tools/generate-settings-spec.c,
which generates a simple XML file describing all libnm setting
properties (still getting the default values via GParamSpec
introspection like generate-settings-spec.c does, but getting the
documentation out of the gtk-doc strings in the GIR file instead).
We were setting GLIB_VERSION_MAX_ALLOWED to 2.34, since we provide
reimplementations of a few 2.34 functions in nm-glib-compat.h. But
this was turning off warnings for the 2.34+ APIs we *didn't* have
compat versions of too.
Fix this by setting MAX_ALLOWED to 2.32 (same as MIN_REQUIRED), and
defining macros to wrap calls to compat-ified functions and disable
deprecation warnings around them.
This points out several places where we were accidentally using 2.34
APIs without noticing, which need to be fixed now.
