@level_desc and @domain_desc are two immutable arrays with information
about logging levels and logging domains. Since they are immutable and
intialized from the start, they are pretty trival w.r.t. tread-safety and
general maintainability (code readability).
Refactor them to be separate variables.
Previously, _nm_logging_clear_platform_logging_cache was an extern variable,
and NMLinuxPlatform would set it to a function pointer at certain points.
That's unnecessary complex, also when trying to make nm-logging thread-safe,
it's just more global variables that need to be considered. Don't do it
that way, but just link in a regular function.
Since commit 9ecdba316 ('platform: create netlink messages directly
without libnl-route-3') we're unconditionally setting IFA_ADDRESS to
the peer address, even if there's no peer and it's all zeroes.
The kernel actually stopped caring somewhere around commit caeaba790
('ipv6: add support of peer address') in v3.10, but Ubuntu Touch likes
to run Android's v3.4 on some poorly supported hardware.
Fixes: 9ecdba316chttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/77
We already need to special handle regular settings (with secrets as
GObject properties) and VPN secrets.
Next, we will also need to special handle WireGuard peers, which can
have secrets too.
Move the code to a virtual function, so that "nm-connection.c" and
"nm-setting.c" does not have explicit per-setting knowledge.
- use cleanup attribute to free memory
- return floating reference from _nm_connection_for_each_secret().
It's more idiomatic that a function that constructs a variant and
returns it, returns a floating variant.
_nm_connection_for_each_secret() (formerly for_each_secret()) and
_nm_connection_find_secret() (formerly find_secret()) operate on a
GVariant of secrets. For that, they implement certain assumptions
of how to handle secrets. For example, it must special-case VPN settings,
because there is no generic abstraction to handle regular secret and VPN
secrets the same.
Such special casing should only be done in libnm-core, at one place.
Move the code to libnm-core as internal API.
nm_setting_get_secret_flags() looks whether we have a suitable "-flags"
data value, or whether we have a secret with that name.
In fact, we know this is a valid secret-name. Even if there are no secret-flags
and the secret (currently) does not exists. We shall not care about the
return value.
Note that nm_setting_get_secret_flags() also for non-secrets will set
the flags to "NONE", which is just what we need.
Instead of special-casing the aggregate implementation for NMSettingVpn,
delegate to a virtual function.
This will also work with other settings, that have properties/secrets
that are not GObject based properties.
While nm_setting_enumerate_values() should not be used anymore, still
extend it to make it workable also for properties that are not based on
GObject properties.
We want to emit a change notification when gendata-based settings (like
NMSettingEthtool) change. But instead of adding a separate signal, just
emit a fake "notify:name" notification.
When the parent device has a device default route (i.e. without
gateway) and we establish a VPN on top of it, 'ip route get' for the
VPN gateway returns a device route, which is the same result we get
for an unreachable VPN gateway. However it is necessary to add the
route to the gateway or otherwise it will possibly become unreachable
once the VPN gets activated.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/93
There is:
1) glib's MAX() macro, which evaluates arguments multiple times,
but yields a constant expression, if the arguments are constant.
2) NM's NM_MAX() macro, which evaluates arguments exactly once,
but never yields a constant expression.
3) systemd's MAX() which is like NM_MAX().
Now, it's sensible to use
char buf[MAX (A_CONSTANT, ANOTHER_CONSTANT)];
and this works with glib's variant (1).
However, when we include systemd headers, 1) gets redefined to 3), and
above no longer works. That is because we we don't allow VLA and systemd's
macro gives not a constant expression.
Add NM_CONST_MAX() macro which is like systemd's CONST_MAX(). It can
only operate on constant arguments.
We named the types inconsistently:
- "p2p-wireless" ("libnm-core/nm-setting-p2p-wireless.h")
- "p2p" ("libnm/nm-p2p-peer.h")
- "p2p-wifi" ("src/devices/wifi/nm-device-p2p-wifi.h")
It seems to me, "libnm/nm-p2p-peer.h" should be qualified with a "Wi-Fi"
specific name. It's not just peer-to-peer, it's Wi-Fi P2P.
Yes, there is an inconsistency now, because there is already
"libnm/nm-access-point.h".
It seems to me (from looking at the internet), that the name "Wi-Fi P2P"
is more common than "P2P Wi-Fi" -- although both are used. There is also
the name "Wi-Fi Direct". But it's not clear which name should be
preferred here, so stick to "Wi-Fi P2P".
In this first commit only rename the files. The following commit will
rename the content.
Having synchronous API is wrong, or at least questionable.
Granted, libnm isn't currently very good about the exact order
of things to happen. However synchronous API by design delays events
while waiting for the response and hence messes up the ordering.
Maybe synchronous API should not be added to libnm.
Or at least, if we have synchronous API, we certainly need an asynchrnous
variant as well (which is still missing).
As synchronous API is not preferred, it should also be named
nm_some_thing_sync(), accompanied by nm_some_thing() and
nm_some_thing_finish(). The name for the synchronous method should be the
odd one and we shouldn't have an nm_some_thing_async(). Yes, libnm is not
consistend about that.
I am going to drop this API for the moment.
- fix leaking hw_address in finalize().
- reorder code.
- avoid double tabs in GObject property definitions.
- hide struct definitions from header.
- don't use signal slots in class structure.
- use NM_GOBJECT_PROPERTIES_DEFINE_BASE().
- add missing NM_AVAILABLE_IN_1_16 annotations.
Don't reallocate peers-array nor set it to %NULL. Instead,
just emit the signal for the peers and take them out one-by-one.
I am slightly surprised, that the peers array does not need to hold
a reference on the NMP2PPeer instances. But that seems intentional.
I think, the libnm code here should be significantly reworked, but
that is for another time.
Also, delay clearing the pointers until finalize() method. For
the most part, it shouldn't make a difference. Still avoid having
the instance in a badly defined state during dispose() (which
theoretically could be called multiple times).
We don't need to remember (and compare) all the bytes that we received.
We can just compare them right away, and remember how many good bytes
we received.
Since we only compare that the HTTP response starts with the expected
response, we need to handle the empty expected response specially
(because, every response has "" as prefix).
So now if connectivity.response is set to "" (empty) we accept:
- HTTP status code 204. We ignore and accept any extra data that we
might receive.
- HTTP status code 200 and an empty (or no) body.
