The GDBusObjectManagerClient's control proxy seems to leak some bits. Not sure
why; but certainly not our fault since it's a private object and the
manager object itself gets finalized.
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
nm_utils_hexstr2bin() is quite similar to hwaddr_aton(), and
nm_utils_bin2hexstr() is similar to _bin2str_buf().
Move them close to each other. Maybe one day they should be
consolidated. But their API is slightly different, so the
consolidation would require some effort.
For now, just move them close to each other, so that it's
clearer that two similar (but distinct) functions exists.
On some architectures, it seems we don't properly expose
the symbol of these static variables from NetworkManager
binary.
Just avoid that and don't instead use a static array
inside the device plugin itself.
While at it, make the arrays all const, which possibly allows
the linker to put those symbols in the read-only section.
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>
It could be that the client is just newer and it's just too harsh to
fail the whole request. Leave the unknown permission in unknown and
possibly proceed filling in the rest.
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.
When the device has an IP interface different from the main one, we
previously took the MTU saved in priv->mtu (which is the MTU initially
set on the underlying interface) and applied it to the IP interface.
This is wrong as it forces the two MTUs to be equal and breaks
connectivity for devices with encapsulation (as PPP). Instead, track
the two MTUs in different variables.
https://bugzilla.redhat.com/show_bug.cgi?id=1385198
- a key
FOO=''
would still allocate a temporary GString and return the allocated
empty string. Don't do that. This saves the g_free() in
svGetValueString() for this common case. We should return
an allocated string only if it is necessary. It is not necessary
for the "" case, and it is inconsistent.
- when returning an empty string, always return the static string "".
No need to seek to the end of value, and return a pointer to that
string.
This happens for example in the case
FOO= # empty value, but trailing stuff
FOO=""
FOO=$'\Uxhallo'
This adds 0.4 seconds to the build time.
You can disable it by setting $NM_BUILD_NO_CREATE_EXPORTS environment
variable. This is useful in the unexpected case that the script
is broken.
Or, if you just want to use a different, non-generated version-script.
Or, if you want to save 0.4 seconds build-time.
- include symbols from the "B" section.
- improve the script, to use libNetworkManager.a instead
of the NetworkManager binary. The former is before stripping
symbols.
Strange, didn't get this failure before...
./src/NetworkManager: symbol lookup error: ./src/devices/wifi/.libs/libnm-device-plugin-wifi.so: undefined symbol: _nm_device_factory_no_default_settings
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.
