In practice, this should only matter when there are multiple
header files with the same name. That is something we try
to avoid already, by giving headers a distinct name.
When building NetworkManager itself, we clearly want to use
double-quotes for including our own headers.
But we also want to do that in our public headers. For example:
./a.c
#include <stdio.h>
#include <nm-1.h>
void main() {
printf ("INCLUDED %s/nm-2.h\n", SYMB);
}
./1/nm-1.h
#include <nm-2.h>
./1/nm-2.h
#define SYMB "1"
./2/nm-2.h
#define SYMB "2"
$ cc -I./2 -I./1 ./a.c
$ ./a.out
INCLUDED 2/nm-2.h
Exceptions to this are
- headers in "shared/nm-utils" that include <NetworkManager.h>. These
headers are copied into projects and hence used like headers owned by
those projects.
- examples/C
The libnm cache types don't have public _new() functions.
However, such types can be easily created using g_object_new()
directly from user code.
Such a usage is not supported. Add an assertion that a valid
dbus-object is present.
This adds definition of a set of known route option attributes to
libnm-core and helper functions.
nm_ip_route_attribute_validate() performs the validation of the
attribute type and, in case of a formatted string attribute, of its
content.
nm_ip_route_get_variant_attribute_spec() returns the attribute format
specifier to be passed to nm_utils_parse_variant_attributes(). Since
at the moment NMIPRoute is the only user of NMVariantAttributeSpec and
the type is opaque to users of the library, the struct is extended to
carry some other data useful for validation.
Various libnm objects (addresses, routes) carry an hash table of
attributes represented as GVariants indexed by name. Add common
routines to convert to and from a string representation.
To parse a string, a knowledge of the supported attributes (and their
types) is needed: we represent it as an opaque type
NMVariantAttributeSpec that callers must query to the library for the
specific object type and pass to the parse function.
Add support for creating dummy devices. This commit adds a D-Bus
interface 'org.freedesktop.NetworkManager.Device.Dummy' which is used
primarily for determining the device type but does not carry any
properties.
The property can be used to tune the authentication timeout. It's
especially useful to speed up the failure in case the port doesn't
support 802.1X and make NM try a different, non-authenticated
connection.
I think NM_CACHED_QUARK_FCN() is better because:
- the implementation is in our hand, meaning it is clear that
putting a "static" before NM_CACHED_QUARK_FCN() is guaranteed to
work -- without relying on G_DEFINE_QUARK() to be defined in a way
that this works (in fact, we currently never do that and instead
make all functions non-static).
- it does not construct function names by appending "_quark".
Thus you can grep for the entire function name and finding
the place where it is implemented.
- same with the stings, where the new macro doesn't stringify the
argument, which is less surpising. Again, now you can grep
for the string including the double quoting.
(yes, I really use grep to understand the source-code)
The -Wimplicit-fallthrough=3 warning is quite flexible of accepting
a fall-through warning.
Some comments were missing or not detected correctly.
Thereby, also change all other comments to follow the exact
same pattern.
The user can't do much about it and we can recover. This is a temporary
measure to avoid unnecessarily bothering the user.
(cherry picked from commit 7fec0755c9)
At some point gobject-introspection added an API to add a library path
and stopped honoring the LD_LIBRARY_PATH (a bug, according to GI
documentation?).
(cherry picked from commit 6c96aafaa9)
The new NMSettingMacsec contains information necessary to establish a
MACsec connection. At the moment we support two different MACsec
modes, both using wpa_supplicant: PSK and EAP.
PSK mode is based on a static CAK key for the MACsec key agreement
protocol, while EAP mode derives keys from a 802.1x authentication and
thus requires the presence of a NMSetting8021x in the connection.
From valgrind:
==21921== Invalid free() / delete / delete[] / realloc()
==21921== at 0x4C2CD5A: free (vg_replace_malloc.c:530)
==21921== by 0x81C4F2D: g_free (gmem.c:189)
==21921== by 0x81AB021: g_error_free (gerror.c:491)
==21921== by 0x81AB325: g_clear_error (gerror.c:674)
==21921== by 0x767B555: reg_request_cb (nm-secret-agent-old.c:616)
==21921== by 0x7A211F2: g_task_return_now (gtask.c:1107)
==21921== by 0x7A21228: complete_in_idle_cb (gtask.c:1121)
==21921== by 0x81BF6B9: g_main_dispatch (gmain.c:3154)
==21921== by 0x81BF6B9: g_main_context_dispatch (gmain.c:3769)
==21921== by 0x81BFA6F: g_main_context_iterate.isra.29 (gmain.c:3840)
==21921== by 0x81BFB1B: g_main_context_iteration (gmain.c:3901)
==21921== by 0x7A4748C: g_application_run (gapplication.c:2381)
==21921== by 0x118AEF: main (main.c:81)
It caused memory corruption and may result in strange nm-applet crashes.
This makes it easier to install the files with proper names.
Also, it makes the makefile rules slightly simpler.
Lastly, the documentation is now generated into docs/api, which makes it
possible to get rid of the awkward relative file names in docbook.
Apparently, the client is used by the services we depend on (firewalld),
and an attempt to start the service would deadlock them.
This was an accidental change anyway.
Related firewalld change: https://github.com/t-woerner/firewalld/pull/171
Before switching to the ObjectManager, the D-Bus property was used to
decide the actual type of the device and the property set manually by
each subclass in its _init() function. Now we determine objects type
based on their D-Bus interface and therefore we can handle the
property like all others, ensuring that we return a known value in
get_property() to avoid warnings in GLib.
This fixes the missing initialization of the property which causes
regressions on clients as nm-applet.
Fixes: 1f5b48a59e
They indicate a server bug (a dangling path of an object that does not
exist). The best we can do probably is to just ignore them and warn.
Based-on-patch-by: Dan Williams <dcbw@redhat.com>
The GetPermissions call is very expensive (~400ms here, an extra
NM->polkit call for every known permission while polkit being really
slow to answer) yet seldom needed.
There's no methods to access the permissions -- they're only
communicated via signals.
Unfortunately, we don't know when a signal is hooked, so we still need
to kick of the call. Nevertheless, we don't need to wait for it to
finish.
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.
