It serves no purpose, because the function always allocates a new
result and returns it. It would make sense, if the output string
would only be cloned when we need to allocate a new string. But
since that optimization is not done, the argument serves no purpose.
Don't log with level <info>. It's not important enough and only
noise. Also, move the logging line outside of nm_policy_init(). At that
point, the policy instance is not yet initialized (much), so we shouldn't
use the logging macro _LOGD().
A property preferably only emits a notify-changed signal when
the value actually changes and it caches the value (so that
between property-changed signals the value is guaranteed not to change).
NMSettings and NMManager both already cache the hostname, because
NMHostnameManager didn't guarantee this basic concept.
Implement it and rely on it from NMSettings and NMPolicy.
And remove the copy of the property from NMManager.
Move the call for nm_dispatcher_call_hostname() from NMHostnameManager
to NMManager. Note that NMPolicy also has a call to the dispatcher
when set-transient-hostname returns. This should be cleaned up later.
Hostname management is complicated. At least, how it is implemented currently.
For example, NMPolicy also sets the hostname (NMPolicy calls
nm_settings_set_transient_hostname() to have hostnamed set the hostname,
but then falls back to sethostname() in settings_set_hostname_cb()).
Also, NMManager tracks the hostname in NM_MANAGER_HOSTNAME too, and
NMPolicy listens to changes from there -- instead of changes from
NMSettings.
Eventually, NMHostnameManager should contain the hostname parts from NMSettings
and NMPolicy.
- anticipate missing callback/ctx->result
- always invoke the result callback when given
- fix leaking GVariant in disconnect_done()
- fix crash due to non-initialized ctx->result
- pass cancellable to g_dbus_proxy_call()
And some fixes:
- proxy creation may fail. Don't handle it by retrying,
but at least don't access the invalid proxy instance.
- quering "DefaultAdapter" did not take a reference to @self
nor was the operation cancellable. This leads to crash
if the instance gets destroyed early.
And some fixes:
- proxy creation may fail. Don't handle it by retrying,
but at least don't access the invalid proxy instance.
- get_properties_cb() did not take a reference to @self
nor was the operation cancellable. This leads to crash
if the instance gets destroyed early.
Fix two issues of the previous code:
- the D-Bus proxy for the modem manager should not get created
synchronously.
- NMModemManager is a singleton, let it track the name-owner
change and the D-Bus proxy, instead of having one per NMDeviceBt.
Don't do non-trivial initialization in nm_device_bt_init(). At
this point, the object is not yet fully created. As we already have
a constructed() implemented, move the initialization there.
Also, bluetooth plugin uses NMModem from the wwan plugin. Don't
include such a foreign header in a "nm-device-bt.h". Instead, forward
declare what we need.
Most of the functions are strictly related to ModemManager. Their
name should hint to that, so that they are clearly separated from
the ofono functions and general purpose functions.
Same for data fields.
It is often wrong to take a reference to keep the instance alive during
the asynchronous request, because it means the instance cannot be
destroyed as long as the (non cancellable) request is bending.
Fix that for NMModemManager and pass a cancallable along.
libcurl employs some typechecking via "curl/typecheck-gcc.h". When
compling with --enable-lto, compilation fails otherwise with:
make[2]: Entering directory '/data/src/NetworkManager'
CC src/src_libNetworkManager_la-nm-connectivity.lo
CCLD src/libNetworkManager.la
CCLD src/libNetworkManagerTest.la
CCLD src/dhcp/tests/test-dhcp-dhclient
src/nm-connectivity.c: In function 'curl_check_connectivity':
src/nm-connectivity.c:147:10: error: call to '_curl_easy_getinfo_err_string' declared with attribute warning: curl_easy_getinfo expects a pointer to char * for this info [-Werror]
eret = curl_easy_getinfo (msg->easy_handle, CURLINFO_PRIVATE, &cb_data);
^
lto1: all warnings being treated as errors
lto-wrapper: fatal error: /usr/bin/gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
For manged=unknown, we don't write the value to the
device state keyfile. The results in an empty file,
or at least, a keyfile that doesn't have device.managed
set.
On read, we must treat a missing device.managed flag as
unknown, and not as unmanaged. Otherwise, on restart
a device becomes marked as explicitly unmanaged.
This was broken by commit 142ebb1 "core: only persist explicit managed
state in device's state file", where we started conditionally
to no longer write the managed state.
Reported-by: Michael Biebl <mbiebl@debian.org>
Fixes: 142ebb1037
- print string value instead of numerical "managed"
- for missing state, print the same format. After all,
some defaults apply and it is interesting to know what
they are.
- config->removed can be replaced by c_list_is_empty(&config->lst)
- downgrade some assertions to nm_assert(). Even without the
assert we crash a few lines later with a NULL pointer access.
That gives almost the same debuggability and discoverability
of the bug.
- use exact type signature for GAsyncReadyCallback and avoid
casting.
- when the name owner disappears, cancel all asynchronous
operations. Note how the new pacrunner instance will anyway
start without configuration, so for all intended purpose, all
pending operations are at that moment obsolete.
Include the circular, doubly-linked list implementation from
c-util/c-list [1], commit 864051de6e7e1c93c782064fbe3a86b4c17ac466.
[1] https://github.com/c-util/c-list
We must not cancel pacrunner_cancellable when the D-Bus proxy is
created. Instead, keep it around and use it later for the asynchronous
D-Bus operations.
This doesn't really matter at the moment, because the pacrunner manager
is only destroyed when NetworkManager is about to terminated. That is
the only time when we actually cancel the asynchronous request. Also,
at that time we no longer iterate the mainloop, so the pending requests
are never completed anyway.
We listen to all RTM_GETLINK messages to get updates on interfaces statuses.
Unfortunately wireless code in the kernel sends those messages with wireless information included
and all other information excluded. When we receive such message we wipe out our valid cached entry
with new object that is almost empty because netlink message didn't contain any information.
Solution to this is to check that incoming message contains MTU field: this field is always
set for complete messages about interfaces and is not set by wireless code.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
https://github.com/NetworkManager/NetworkManager/pull/17
