2005-10-28 02:49:11 +00:00
|
|
|
[encoding: UTF-8]
|
2004-08-26 23:13:09 +00:00
|
|
|
# List of source files containing translatable strings.
|
|
|
|
|
# Please keep this file sorted alphabetically.
|
2014-10-30 14:45:43 +00:00
|
|
|
clients/cli/agent.c
|
2014-07-22 21:55:13 +00:00
|
|
|
clients/cli/common.c
|
|
|
|
|
clients/cli/connections.c
|
|
|
|
|
clients/cli/devices.c
|
2014-10-01 12:34:56 +00:00
|
|
|
clients/cli/general.c
|
2014-07-22 21:55:13 +00:00
|
|
|
clients/cli/nmcli.c
|
2014-10-30 10:25:55 +00:00
|
|
|
clients/cli/polkit-agent.c
|
2014-07-22 21:55:13 +00:00
|
|
|
clients/cli/settings.c
|
|
|
|
|
clients/cli/utils.c
|
2018-04-27 09:26:47 +00:00
|
|
|
clients/cli/utils.h
|
2017-03-28 10:16:31 +00:00
|
|
|
clients/common/nm-client-utils.c
|
2017-04-12 13:19:26 +00:00
|
|
|
clients/common/nm-meta-setting-access.c
|
2017-03-28 09:38:00 +00:00
|
|
|
clients/common/nm-meta-setting-desc.c
|
2014-10-29 12:15:29 +00:00
|
|
|
clients/common/nm-polkit-listener.c
|
2014-10-14 10:37:00 +00:00
|
|
|
clients/common/nm-secret-agent-simple.c
|
2015-12-07 09:18:55 +00:00
|
|
|
clients/common/nm-vpn-helpers.c
|
2018-01-11 16:02:13 +00:00
|
|
|
clients/common/settings-docs.h.in
|
2014-07-22 21:55:13 +00:00
|
|
|
clients/nm-online.c
|
|
|
|
|
clients/tui/newt/nmt-newt-utils.c
|
|
|
|
|
clients/tui/nm-editor-utils.c
|
|
|
|
|
clients/tui/nmt-connect-connection-list.c
|
|
|
|
|
clients/tui/nmt-device-entry.c
|
|
|
|
|
clients/tui/nmt-edit-connection-list.c
|
2014-10-31 20:01:27 +00:00
|
|
|
clients/tui/nmt-editor-section.c
|
2014-07-22 21:55:13 +00:00
|
|
|
clients/tui/nmt-editor.c
|
|
|
|
|
clients/tui/nmt-mtu-entry.c
|
|
|
|
|
clients/tui/nmt-page-bond.c
|
|
|
|
|
clients/tui/nmt-page-bridge-port.c
|
|
|
|
|
clients/tui/nmt-page-bridge.c
|
2014-09-16 12:38:47 +00:00
|
|
|
clients/tui/nmt-page-dsl.c
|
2014-07-22 21:55:13 +00:00
|
|
|
clients/tui/nmt-page-ethernet.c
|
|
|
|
|
clients/tui/nmt-page-infiniband.c
|
|
|
|
|
clients/tui/nmt-page-ip4.c
|
|
|
|
|
clients/tui/nmt-page-ip6.c
|
2016-11-04 13:00:04 +00:00
|
|
|
clients/tui/nmt-page-ip-tunnel.c
|
2014-09-16 12:38:47 +00:00
|
|
|
clients/tui/nmt-page-ppp.c
|
2014-07-22 21:55:13 +00:00
|
|
|
clients/tui/nmt-page-team-port.c
|
|
|
|
|
clients/tui/nmt-page-team.c
|
|
|
|
|
clients/tui/nmt-page-vlan.c
|
|
|
|
|
clients/tui/nmt-page-wifi.c
|
|
|
|
|
clients/tui/nmt-password-dialog.c
|
|
|
|
|
clients/tui/nmt-password-fields.c
|
|
|
|
|
clients/tui/nmt-route-editor.c
|
|
|
|
|
clients/tui/nmt-route-table.c
|
|
|
|
|
clients/tui/nmt-slave-list.c
|
|
|
|
|
clients/tui/nmt-widget-list.c
|
|
|
|
|
clients/tui/nmtui-connect.c
|
|
|
|
|
clients/tui/nmtui-edit.c
|
|
|
|
|
clients/tui/nmtui-hostname.c
|
|
|
|
|
clients/tui/nmtui.c
|
2018-08-29 16:58:14 +00:00
|
|
|
libnm-core/nm-crypto.c
|
|
|
|
|
libnm-core/nm-crypto-gnutls.c
|
|
|
|
|
libnm-core/nm-crypto-nss.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-connection.c
|
2015-04-05 09:17:09 +00:00
|
|
|
libnm-core/nm-dbus-utils.c
|
2021-02-07 20:12:20 +00:00
|
|
|
libnm-core/nm-keyfile-utils.c
|
|
|
|
|
libnm-core/nm-keyfile.c
|
2020-06-09 16:06:15 +00:00
|
|
|
libnm-core/nm-libnm-core-aux/nm-libnm-core-aux.c
|
2020-08-27 16:18:31 +00:00
|
|
|
libnm-core/nm-libnm-core-intern/nm-libnm-core-utils.c
|
2018-05-22 13:41:29 +00:00
|
|
|
libnm-core/nm-setting-6lowpan.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-setting-8021x.c
|
|
|
|
|
libnm-core/nm-setting-adsl.c
|
|
|
|
|
libnm-core/nm-setting-bluetooth.c
|
|
|
|
|
libnm-core/nm-setting-bond.c
|
|
|
|
|
libnm-core/nm-setting-bridge-port.c
|
|
|
|
|
libnm-core/nm-setting-bridge.c
|
|
|
|
|
libnm-core/nm-setting-cdma.c
|
|
|
|
|
libnm-core/nm-setting-connection.c
|
|
|
|
|
libnm-core/nm-setting-dcb.c
|
libnm, cli, ifcfg-rh: add NMSettingEthtool setting
Note that in NetworkManager API (D-Bus, libnm, and nmcli),
the features are called "feature-xyz". The "feature-" prefix
is used, because NMSettingEthtool possibly will gain support
for options that are not only -K|--offload|--features, for
example -C|--coalesce.
The "xzy" suffix is either how ethtool utility calls the feature
("tso", "rx"). Or, if ethtool utility specifies no alias for that
feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation").
If possible, we prefer ethtool utility's naming.
Also note, how the features "feature-sg", "feature-tso", and
"feature-tx" actually refer to multiple underlying kernel features
at once. This too follows what ethtool utility does.
The functionality is not yet implemented server-side.
2018-07-16 21:37:55 +00:00
|
|
|
libnm-core/nm-setting-ethtool.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-setting-gsm.c
|
|
|
|
|
libnm-core/nm-setting-infiniband.c
|
2014-10-19 21:30:10 +00:00
|
|
|
libnm-core/nm-setting-ip-config.c
|
2019-01-28 11:39:38 +00:00
|
|
|
libnm-core/nm-setting-ip-tunnel.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-setting-ip4-config.c
|
|
|
|
|
libnm-core/nm-setting-ip6-config.c
|
2016-06-30 16:20:43 +00:00
|
|
|
libnm-core/nm-setting-macsec.c
|
2015-09-17 16:13:49 +00:00
|
|
|
libnm-core/nm-setting-macvlan.c
|
2020-04-21 15:39:19 +00:00
|
|
|
libnm-core/nm-setting-match.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-setting-olpc-mesh.c
|
2019-01-28 11:39:38 +00:00
|
|
|
libnm-core/nm-setting-ovs-bridge.c
|
2020-11-02 16:29:26 +00:00
|
|
|
libnm-core/nm-setting-ovs-external-ids.c
|
2017-08-01 16:36:34 +00:00
|
|
|
libnm-core/nm-setting-ovs-interface.c
|
2017-08-01 16:36:34 +00:00
|
|
|
libnm-core/nm-setting-ovs-patch.c
|
2017-10-02 07:03:19 +00:00
|
|
|
libnm-core/nm-setting-ovs-port.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-setting-ppp.c
|
|
|
|
|
libnm-core/nm-setting-pppoe.c
|
2016-08-23 09:37:38 +00:00
|
|
|
libnm-core/nm-setting-proxy.c
|
2018-05-25 10:05:24 +00:00
|
|
|
libnm-core/nm-setting-sriov.c
|
2017-11-16 16:35:20 +00:00
|
|
|
libnm-core/nm-setting-tc-config.c
|
2014-07-07 15:05:10 +00:00
|
|
|
libnm-core/nm-setting-team-port.c
|
2019-01-28 11:39:38 +00:00
|
|
|
libnm-core/nm-setting-team.c
|
2015-09-14 20:56:51 +00:00
|
|
|
libnm-core/nm-setting-tun.c
|
2017-03-24 11:41:04 +00:00
|
|
|
libnm-core/nm-setting-user.c
|
2020-11-12 20:58:13 +00:00
|
|
|
libnm-core/nm-setting-veth.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-setting-vlan.c
|
2019-12-05 09:13:34 +00:00
|
|
|
libnm-core/nm-setting-vrf.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-setting-vpn.c
|
2015-10-13 07:09:54 +00:00
|
|
|
libnm-core/nm-setting-vxlan.c
|
2019-01-28 11:39:38 +00:00
|
|
|
libnm-core/nm-setting-wifi-p2p.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-setting-wimax.c
|
|
|
|
|
libnm-core/nm-setting-wired.c
|
2018-12-27 15:48:30 +00:00
|
|
|
libnm-core/nm-setting-wireguard.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-setting-wireless-security.c
|
|
|
|
|
libnm-core/nm-setting-wireless.c
|
2018-03-09 09:51:49 +00:00
|
|
|
libnm-core/nm-setting-wpan.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm-core/nm-setting.c
|
libnm: rework team handling of JSON config
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
2019-05-06 10:36:41 +00:00
|
|
|
libnm-core/nm-team-utils.c
|
2014-11-25 22:01:55 +00:00
|
|
|
libnm-core/nm-utils.c
|
2015-05-28 20:16:00 +00:00
|
|
|
libnm-core/nm-vpn-editor-plugin.c
|
2015-05-22 11:26:40 +00:00
|
|
|
libnm-core/nm-vpn-plugin-info.c
|
libnm: refactor caching of D-Bus objects in NMClient
No longer use GDBusObjectMangaerClient and gdbus-codegen generated classes
for the NMClient cache. Instead, use GDBusConnection directly and a
custom implementation (NMLDBusObject) for caching D-Bus' ObjectManager
data.
CHANGES
-------
- This is a complete rework. I think the previous implementation was
difficult to understand. There were unfixed bugs and nobody understood
the code well enough to fix them. Maybe somebody out there understood the
code, but I certainly did not. At least nobody provided patches to fix those
issues. I do believe that this implementation is more straightforward and
easier to understand. It removes a lot of layers of code. Whether this claim
of simplicity is true, each reader must decide for himself/herself. Note
that it is still fairly complex.
- There was a lingering performance issue with large number of D-Bus
objects. The patch tries hard that the implementation scales well. Of
course, when we cache N objects that have N-to-M references to other,
we still are fundamentally O(N*M) for runtime and memory consumption (with
M being the number of references between objects). But each part should behave
efficiently and well.
- Play well with GMainContext. libnm code (NMClient) is generally not
thread safe. However, it should work to use multiple instances in
parallel, as long as each access to a NMClient is through the caller's
GMainContext. This follows glib's style and effectively allows to use NMClient
in a multi threaded scenario. This implies to stick to a main context
upon construction and ensure that callbacks are only invoked when
iterating that context. Also, NMClient itself shall never iterate the
caller's context. This also means, libnm must never use g_idle_add() or
g_timeout_add(), as those enqueue sources in the g_main_context_default()
context.
- Get ordering of messages right. All events are consistently enqueued
in a GMainContext and processed strictly in order. For example,
previously "nm-object.c" tried to combine signals and emit them on an
idle handler. That is wrong, signals must be emitted in the right order
and when they happen. Note that when using GInitable's synchronous initialization
to initialize the NMClient instance, NMClient internally still operates fully
asynchronously. In that case NMClient has an internal main context.
- NMClient takes over most of the functionality. When using D-Bus'
ObjectManager interface, one needs to handle basically the entire state
of the D-Bus interface. That cannot be separated well into distinct
parts, and even if you try, you just end up having closely related code
in different source files. Spreading related code does not make it
easier to understand, on the contrary. That means, NMClient is
inherently complex as it contains most of the logic. I think that is
not avoidable, but it's not as bad as it sounds.
- NMClient processes D-Bus messages and state changes in separate steps.
First NMClient unpacks the message (e.g. _dbus_handle_properties_changed()) and
keeps track of the changed data. Then we update the GObject instances
(_dbus_handle_obj_changed_dbus()) without emitting any signals yet. Finally,
we emit all signals and notifications that were collected
(_dbus_handle_changes_commit()). Note that for example during the initial
GetManagedObjects() reply, NMClient receive a large amount of state at once.
But we first apply all the changes to our GObject instances before
emitting any signals. The result is that signals are always emitted in a moment
when the cache is consistent. The unavoidable downside is that when you receive
a property changed signal, possibly many other properties changed
already and more signals are about to be emitted.
- NMDeviceWifi no longer modifies the content of the cache from client side
during poke_wireless_devices_with_rf_status(). The content of the cache
should be determined by D-Bus alone and follow what NetworkManager
service exposes. Local modifications should be avoided.
- This aims to bring no API/ABI change, though it does of course bring
various subtle changes in behavior. Those should be all for the better, but the
goal is not to break any existing clients. This does change internal
(albeit externally visible) API, like dropping NM_OBJECT_DBUS_OBJECT_MANAGER
property and NMObject no longer implementing GInitableIface and GAsyncInitableIface.
- Some uses of gdbus-codegen classes remain in NMVpnPluginOld, NMVpnServicePlugin
and NMSecretAgentOld. These are independent of NMClient/NMObject and
should be reworked separately.
- While we no longer use generated classes from gdbus-codegen, we don't
need more glue code than before. Also before we constructed NMPropertiesInfo and
a had large amount of code to propagate properties from NMDBus* to NMObject.
That got completely reworked, but did not fundamentally change. You still need
about the same effort to create the NMLDBusMetaIface. Not using
generated bindings did not make anything worse (which tells about the
usefulness of generated code, at least in the way it was used).
- NMLDBusMetaIface and other meta data is static and immutable. This
avoids copying them around. Also, macros like NML_DBUS_META_PROPERTY_INIT_U()
have compile time checks to ensure the property types matches. It's pretty hard
to misuse them because it won't compile.
- The meta data now explicitly encodes the expected D-Bus types and
makes sure never to accept wrong data. That would only matter when the
server (accidentally or intentionally) exposes unexpected types on
D-Bus. I don't think that was previously ensured in all cases.
For example, demarshal_generic() only cared about the GObject property
type, it didn't know the expected D-Bus type.
- Previously GDBusObjectManager would sometimes emit warnings (g_log()). Those
probably indicated real bugs. In any case, it prevented us from running CI
with G_DEBUG=fatal-warnings, because there would be just too many
unrelated crashes. Now we log debug messages that can be enabled with
"LIBNM_CLIENT_DEBUG=trace". Some of these messages can also be turned
into g_warning()/g_critical() by setting LIBNM_CLIENT_DEBUG=warning,error.
Together with G_DEBUG=fatal-warnings, this turns them into assertions.
Note that such "assertion failures" might also happen because of a server
bug (or change). Thus these are not common assertions that indicate a bug
in libnm and are thus not armed unless explicitly requested. In our CI we
should now always run with LIBNM_CLIENT_DEBUG=warning,error and
G_DEBUG=fatal-warnings and to catch bugs. Note that currently
NetworkManager has bugs in this regard, so enabling this will result in
assertion failures. That should be fixed first.
- Note that this changes the order in which we emit "notify:devices" and
"device-added" signals. I think it makes the most sense to emit first
"device-removed", then "notify:devices", and finally "device-added"
signals.
This changes behavior for commit 52ae28f6e5bf ('libnm: queue
added/removed signals and suppress uninitialized notifications'),
but I don't think that users should actually rely on the order. Still,
the new order makes the most sense to me.
- In NetworkManager, profiles can be invisible to the user by setting
"connection.permissions". Such profiles would be hidden by NMClient's
nm_client_get_connections() and their "connection-added"/"connection-removed"
signals.
Note that NMActiveConnection's nm_active_connection_get_connection()
and NMDevice's nm_device_get_available_connections() still exposes such
hidden NMRemoteConnection instances. This behavior was preserved.
NUMBERS
-------
I compared 3 versions of libnm.
[1] 962297f9085d, current tip of nm-1-20 branch
[2] 4fad8c7c642e, current master, immediate parent of this patch
[3] this patch
All tests were done on Fedora 31, x86_64, gcc 9.2.1-1.fc31.
The libraries were build with
$ ./contrib/fedora/rpm/build_clean.sh -g -w test -W debug
Note that RPM build already stripped the library.
---
N1) File size of libnm.so.0.1.0 in bytes. There currently seems to be a issue
on Fedora 31 generating wrong ELF notes. Usually, libnm is smaller but
in these tests it had large (and bogus) ELF notes. Anyway, the point
is to show the relative sizes, so it doesn't matter).
[1] 4075552 (102.7%)
[2] 3969624 (100.0%)
[3] 3705208 ( 93.3%)
---
N2) `size /usr/lib64/libnm.so.0.1.0`:
text data bss dec hex filename
[1] 1314569 (102.0%) 69980 ( 94.8%) 10632 ( 80.4%) 1395181 (101.4%) 1549ed /usr/lib64/libnm.so.0.1.0
[2] 1288410 (100.0%) 73796 (100.0%) 13224 (100.0%) 1375430 (100.0%) 14fcc6 /usr/lib64/libnm.so.0.1.0
[3] 1229066 ( 95.4%) 65248 ( 88.4%) 13400 (101.3%) 1307714 ( 95.1%) 13f442 /usr/lib64/libnm.so.0.1.0
---
N3) Performance test with test-client.py. With checkout of [2], run
```
prepare_checkout() {
rm -rf /tmp/nm-test && \
git checkout -B test 4fad8c7c642e && \
git clean -fdx && \
./autogen.sh --prefix=/tmp/nm-test && \
make -j 5 install && \
make -j 5 check-local-clients-tests-test-client
}
prepare_test() {
NM_TEST_REGENERATE=1 NM_TEST_CLIENT_BUILDDIR="/data/src/NetworkManager" NM_TEST_CLIENT_NMCLI_PATH=/usr/bin/nmcli python3 ./clients/tests/test-client.py -v
}
do_test() {
for i in {1..10}; do
NM_TEST_CLIENT_BUILDDIR="/data/src/NetworkManager" NM_TEST_CLIENT_NMCLI_PATH=/usr/bin/nmcli python3 ./clients/tests/test-client.py -v || return -1
done
echo "done!"
}
prepare_checkout
prepare_test
time do_test
```
[1] real 2m14.497s (101.3%) user 5m26.651s (100.3%) sys 1m40.453s (101.4%)
[2] real 2m12.800s (100.0%) user 5m25.619s (100.0%) sys 1m39.065s (100.0%)
[3] real 1m54.915s ( 86.5%) user 4m18.585s ( 79.4%) sys 1m32.066s ( 92.9%)
---
N4) Performance. Run NetworkManager from build [2] and setup a large number
of profiles (551 profiles and 515 devices, mostly unrealized). This
setup is already at the edge of what NetworkManager currently can
handle. Of course, that is a different issue. Here we just check how
long plain `nmcli` takes on the system.
```
do_cleanup() {
for UUID in $(nmcli -g NAME,UUID connection show | sed -n 's/^xx-c-.*:\([^:]\+\)$/\1/p'); do
nmcli connection delete uuid "$UUID"
done
for DEVICE in $(nmcli -g DEVICE device status | grep '^xx-i-'); do
nmcli device delete "$DEVICE"
done
}
do_setup() {
do_cleanup
for i in {1..30}; do
nmcli connection add type bond autoconnect no con-name xx-c-bond-$i ifname xx-i-bond-$i ipv4.method disabled ipv6.method ignore
for j in $(seq $i 30); do
nmcli connection add type vlan autoconnect no con-name xx-c-vlan-$i-$j vlan.id $j ifname xx-i-vlan-$i-$j vlan.parent xx-i-bond-$i ipv4.method disabled ipv6.method ignore
done
done
systemctl restart NetworkManager.service
sleep 5
}
do_test() {
perf stat -r 50 -B nmcli 1>/dev/null
}
do_test
```
[1]
Performance counter stats for 'nmcli' (50 runs):
456.33 msec task-clock:u # 1.093 CPUs utilized ( +- 0.44% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
5,900 page-faults:u # 0.013 M/sec ( +- 0.02% )
1,408,675,453 cycles:u # 3.087 GHz ( +- 0.48% )
1,594,741,060 instructions:u # 1.13 insn per cycle ( +- 0.02% )
368,744,018 branches:u # 808.061 M/sec ( +- 0.02% )
4,566,058 branch-misses:u # 1.24% of all branches ( +- 0.76% )
0.41761 +- 0.00282 seconds time elapsed ( +- 0.68% )
[2]
Performance counter stats for 'nmcli' (50 runs):
477.99 msec task-clock:u # 1.088 CPUs utilized ( +- 0.36% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
5,948 page-faults:u # 0.012 M/sec ( +- 0.03% )
1,471,133,482 cycles:u # 3.078 GHz ( +- 0.36% )
1,655,275,369 instructions:u # 1.13 insn per cycle ( +- 0.02% )
382,595,152 branches:u # 800.433 M/sec ( +- 0.02% )
4,746,070 branch-misses:u # 1.24% of all branches ( +- 0.49% )
0.43923 +- 0.00242 seconds time elapsed ( +- 0.55% )
[3]
Performance counter stats for 'nmcli' (50 runs):
352.36 msec task-clock:u # 1.027 CPUs utilized ( +- 0.32% )
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
4,790 page-faults:u # 0.014 M/sec ( +- 0.26% )
1,092,341,186 cycles:u # 3.100 GHz ( +- 0.26% )
1,209,045,283 instructions:u # 1.11 insn per cycle ( +- 0.02% )
281,708,462 branches:u # 799.499 M/sec ( +- 0.01% )
3,101,031 branch-misses:u # 1.10% of all branches ( +- 0.61% )
0.34296 +- 0.00120 seconds time elapsed ( +- 0.35% )
---
N5) same setup as N4), but run `PAGER= /bin/time -v nmcli`:
[1]
Command being timed: "nmcli"
User time (seconds): 0.42
System time (seconds): 0.04
Percent of CPU this job got: 107%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.43
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 34456
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 6128
Voluntary context switches: 1298
Involuntary context switches: 1106
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
[2]
Command being timed: "nmcli"
User time (seconds): 0.44
System time (seconds): 0.04
Percent of CPU this job got: 108%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.44
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 34452
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 6169
Voluntary context switches: 1849
Involuntary context switches: 142
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
[3]
Command being timed: "nmcli"
User time (seconds): 0.32
System time (seconds): 0.02
Percent of CPU this job got: 102%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.34
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 29196
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 5059
Voluntary context switches: 919
Involuntary context switches: 685
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
---
N6) same setup as N4), but run `nmcli monitor` and look at `ps aux` for
the RSS size.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
[1] me 1492900 21.0 0.2 461348 33248 pts/10 Sl+ 15:02 0:00 nmcli monitor
[2] me 1490721 5.0 0.2 461496 33548 pts/10 Sl+ 15:00 0:00 nmcli monitor
[3] me 1495801 16.5 0.1 459476 28692 pts/10 Sl+ 15:04 0:00 nmcli monitor
2019-10-30 10:42:58 +00:00
|
|
|
libnm/nm-client.c
|
2018-05-22 14:45:05 +00:00
|
|
|
libnm/nm-device-6lowpan.c
|
libnm: merge device-type-specific errors into NMDeviceError
As with the settings, each device type was defining its own error
type, containing either redundant or non-useful error codes. Drop all
of the subtype-specific errors, and reduce things to just
NM_DEVICE_ERROR_FAILED, NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION, and
NM_DEVICE_ERROR_INVALID_CONNECTION.
The device-type-specific errors were only returned from their
nm_device_connection_compatible() implementations, so this is also a
good opportunity to simplify those, by moving duplicated functionality
into the base NMDevice implementation, and then allowing the
subclasses to assume that the connection has already been validated in
their own code. Most of the implementations now just check that the
connection has the correct type for the device (which can't be done at
the NMDevice level since some device types (eg, Ethernet) support
multiple connection types.)
Also, make sure that all of the error messages are localized.
2014-10-11 18:44:10 +00:00
|
|
|
libnm/nm-device-adsl.c
|
|
|
|
|
libnm/nm-device-bond.c
|
|
|
|
|
libnm/nm-device-bridge.c
|
|
|
|
|
libnm/nm-device-bt.c
|
2017-01-31 13:14:33 +00:00
|
|
|
libnm/nm-device-dummy.c
|
libnm: merge device-type-specific errors into NMDeviceError
As with the settings, each device type was defining its own error
type, containing either redundant or non-useful error codes. Drop all
of the subtype-specific errors, and reduce things to just
NM_DEVICE_ERROR_FAILED, NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION, and
NM_DEVICE_ERROR_INVALID_CONNECTION.
The device-type-specific errors were only returned from their
nm_device_connection_compatible() implementations, so this is also a
good opportunity to simplify those, by moving duplicated functionality
into the base NMDevice implementation, and then allowing the
subclasses to assume that the connection has already been validated in
their own code. Most of the implementations now just check that the
connection has the correct type for the device (which can't be done at
the NMDevice level since some device types (eg, Ethernet) support
multiple connection types.)
Also, make sure that all of the error messages are localized.
2014-10-11 18:44:10 +00:00
|
|
|
libnm/nm-device-ethernet.c
|
|
|
|
|
libnm/nm-device-generic.c
|
|
|
|
|
libnm/nm-device-infiniband.c
|
2015-11-12 16:46:39 +00:00
|
|
|
libnm/nm-device-ip-tunnel.c
|
2015-12-09 10:51:43 +00:00
|
|
|
libnm/nm-device-macvlan.c
|
libnm: merge device-type-specific errors into NMDeviceError
As with the settings, each device type was defining its own error
type, containing either redundant or non-useful error codes. Drop all
of the subtype-specific errors, and reduce things to just
NM_DEVICE_ERROR_FAILED, NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION, and
NM_DEVICE_ERROR_INVALID_CONNECTION.
The device-type-specific errors were only returned from their
nm_device_connection_compatible() implementations, so this is also a
good opportunity to simplify those, by moving duplicated functionality
into the base NMDevice implementation, and then allowing the
subclasses to assume that the connection has already been validated in
their own code. Most of the implementations now just check that the
connection has the correct type for the device (which can't be done at
the NMDevice level since some device types (eg, Ethernet) support
multiple connection types.)
Also, make sure that all of the error messages are localized.
2014-10-11 18:44:10 +00:00
|
|
|
libnm/nm-device-modem.c
|
|
|
|
|
libnm/nm-device-olpc-mesh.c
|
2017-10-10 09:04:32 +00:00
|
|
|
libnm/nm-device-ovs-bridge.c
|
2017-10-10 09:04:32 +00:00
|
|
|
libnm/nm-device-ovs-interface.c
|
2017-10-10 09:04:32 +00:00
|
|
|
libnm/nm-device-ovs-port.c
|
libnm: merge device-type-specific errors into NMDeviceError
As with the settings, each device type was defining its own error
type, containing either redundant or non-useful error codes. Drop all
of the subtype-specific errors, and reduce things to just
NM_DEVICE_ERROR_FAILED, NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION, and
NM_DEVICE_ERROR_INVALID_CONNECTION.
The device-type-specific errors were only returned from their
nm_device_connection_compatible() implementations, so this is also a
good opportunity to simplify those, by moving duplicated functionality
into the base NMDevice implementation, and then allowing the
subclasses to assume that the connection has already been validated in
their own code. Most of the implementations now just check that the
connection has the correct type for the device (which can't be done at
the NMDevice level since some device types (eg, Ethernet) support
multiple connection types.)
Also, make sure that all of the error messages are localized.
2014-10-11 18:44:10 +00:00
|
|
|
libnm/nm-device-team.c
|
2019-01-28 11:39:38 +00:00
|
|
|
libnm/nm-device-tun.c
|
2020-11-12 20:58:13 +00:00
|
|
|
libnm/nm-device-veth.c
|
libnm: merge device-type-specific errors into NMDeviceError
As with the settings, each device type was defining its own error
type, containing either redundant or non-useful error codes. Drop all
of the subtype-specific errors, and reduce things to just
NM_DEVICE_ERROR_FAILED, NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION, and
NM_DEVICE_ERROR_INVALID_CONNECTION.
The device-type-specific errors were only returned from their
nm_device_connection_compatible() implementations, so this is also a
good opportunity to simplify those, by moving duplicated functionality
into the base NMDevice implementation, and then allowing the
subclasses to assume that the connection has already been validated in
their own code. Most of the implementations now just check that the
connection has the correct type for the device (which can't be done at
the NMDevice level since some device types (eg, Ethernet) support
multiple connection types.)
Also, make sure that all of the error messages are localized.
2014-10-11 18:44:10 +00:00
|
|
|
libnm/nm-device-vlan.c
|
2019-12-05 09:36:54 +00:00
|
|
|
libnm/nm-device-vrf.c
|
2015-10-15 19:57:11 +00:00
|
|
|
libnm/nm-device-vxlan.c
|
2019-01-28 11:39:38 +00:00
|
|
|
libnm/nm-device-wifi-p2p.c
|
libnm: merge device-type-specific errors into NMDeviceError
As with the settings, each device type was defining its own error
type, containing either redundant or non-useful error codes. Drop all
of the subtype-specific errors, and reduce things to just
NM_DEVICE_ERROR_FAILED, NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION, and
NM_DEVICE_ERROR_INVALID_CONNECTION.
The device-type-specific errors were only returned from their
nm_device_connection_compatible() implementations, so this is also a
good opportunity to simplify those, by moving duplicated functionality
into the base NMDevice implementation, and then allowing the
subclasses to assume that the connection has already been validated in
their own code. Most of the implementations now just check that the
connection has the correct type for the device (which can't be done at
the NMDevice level since some device types (eg, Ethernet) support
multiple connection types.)
Also, make sure that all of the error messages are localized.
2014-10-11 18:44:10 +00:00
|
|
|
libnm/nm-device-wifi.c
|
|
|
|
|
libnm/nm-device-wimax.c
|
2018-03-09 16:19:36 +00:00
|
|
|
libnm/nm-device-wpan.c
|
libnm: merge device-type-specific errors into NMDeviceError
As with the settings, each device type was defining its own error
type, containing either redundant or non-useful error codes. Drop all
of the subtype-specific errors, and reduce things to just
NM_DEVICE_ERROR_FAILED, NM_DEVICE_ERROR_INCOMPATIBLE_CONNECTION, and
NM_DEVICE_ERROR_INVALID_CONNECTION.
The device-type-specific errors were only returned from their
nm_device_connection_compatible() implementations, so this is also a
good opportunity to simplify those, by moving duplicated functionality
into the base NMDevice implementation, and then allowing the
subclasses to assume that the connection has already been validated in
their own code. Most of the implementations now just check that the
connection has the correct type for the device (which can't be done at
the NMDevice level since some device types (eg, Ethernet) support
multiple connection types.)
Also, make sure that all of the error messages are localized.
2014-10-11 18:44:10 +00:00
|
|
|
libnm/nm-device.c
|
2014-07-04 17:26:57 +00:00
|
|
|
libnm/nm-object.c
|
|
|
|
|
libnm/nm-remote-connection.c
|
libnm/secret-agent: rework NMSecretAgentOld
Note that the name "NMSecretAgentOld" comes from when libnm was forked
from libnm-glib. There was a plan to rework the secret agent API and
replace it by a better one. That didn't happen (yet), instead our one
and only agent implementation is still lacking. Don't add a new API, instead
try to improve the existing one, without breaking existing users. Just
get over the fact that the name "NMSecretAgentOld" is ugly.
Also note how nm-applet uses NMSecretAgentOld. It subtypes a class
AppletAgent. The constructor applet_agent_new() is calling the synchronous
g_initable_init() initialization with auto-register enabled. As it was,
g_initable_init() would call nm_secret_agent_old_register(), and if the
"Register" call failed, initialization failed for good. There are even
unit tests that test this behavior. This is bad behavior. It means, when
you start nm-applet without NetworkManager running, it will fail to create
the AppletAgent instance. It would hence be the responsibility of the applet
to recover from this situation (e.g. by retrying after timeout or watching
the D-Bus name owner). Of course, nm-applet doesn't do that and won't recover
from such a failure.
NMSecretAgentOld must try hard not to fail and recover automatically. The
user of the API is not interested in implementing the registration,
unregistration and retry handling. Instead, it should just work best
effort and transparently to the user of the API.
Differences:
- no longer use gdbus-codegen generate bindings. Use GDBusConnection
directly instead. These generated proxies complicate the code by
introducing an additional, stateful layer.
- properly handle GMainContext and synchronous initialization by using an
internal GMainContext.
With this NMSecretAgentOld can be used in a multi threaded context
with separate GMainContext. This does not mean that the object
itself became thread safe, but that the GMainContext gives the means
to coordinate multi-threaded access.
- there are no more blocking calls except g_initiable_init() which
iterates an internal GMainContext until initialization completes.
- obtaining the Unix user ID with "GetConnectionUnixUser" to authenticate
the server is now done asynchronously and only once per name-owner.
- NMSecretAgentOld will now register/export the Agent D-Bus object
already during initialization and stay registered as long as the
instance is alive. This is because usually registering a D-Bus
object would not fail, unless the D-Bus path is already taken.
Such an error would mean that another agent is registered for the same
GDBusConnection, that likely would be a bug in the caller. Hence,
such an issue is truly non-recoverable and should be reported early to
the user. There is a change in behavior compared to before, where previously
the D-Bus object would only be registered while the instance is enabled.
This makes a difference if the user intended to keep the NMSecretAgentOld
instance around in an unregistered state.
Note that nm_secret_agent_old_destroy() was added to really unregister
the D-Bus object. A destroyed instance can no longer be registered.
- the API no longer fully exposes the current registration state. The
user either enables or disables the agent. Then, in the background
NMSecretAgentOld will register, and serve requests as they come. It
will also always automatically re-register and it can de-facto no
longer fail. That is, there might be a failure to register, or the
NetworkManager peer might not be authenticated (non-root) or there
might be some other error, or NetworkManager might not be running.
But such errors are not exposed to the user. The instance is just not
able to provide the secrets in those cases, but it may recover if the
problem can be resolved.
- In particular, it makes no sense that nm_secret_agent_old_register*()
fails, returns an error, or waits until registration is complete. This
API is now only to enable/disable the agent. It is idempotent and
won't fail (there is a catch, see next point).
In particular, nm_secret_agent_old_unregister*() cannot fail anymore.
- However, with the previous point there is a problem/race. When you create
a NMSecretAgentOld instance and immediately afterwards activate a
profile, then you want to be sure that the registration is complete
first. Otherwise, NetworkManager might fail the activation because
no secret agent registered yet. A partial solution for this is
that g_initiable_init()/g_async_initable_init_async() will block
until registration is complete (or with or without success). That means,
if NetworkManager is running, initializing the NMSecretAgentOld will
wait until registration is complete (or failed). However, that does not
solve the race if NetworkManager was not running when creating the
instance.
To solve that race, the user may call nm_secret_agent_old_register_async()
and wait for the command to finish before starting activating. While
async registration no longer fails (in the sense of leaving the agent
permanently disconnected), it will try to ensure that we are
successfully registered and ready to serve requests. By using this
API correctly, a race can be avoided and the user can know that the
instance is now ready to serve request.
2019-12-24 12:26:50 +00:00
|
|
|
libnm/nm-secret-agent-old.c
|
2014-10-28 21:07:42 +00:00
|
|
|
libnm/nm-vpn-plugin-old.c
|
2015-06-02 08:50:29 +00:00
|
|
|
libnm/nm-vpn-service-plugin.c
|
2016-11-03 12:25:36 +00:00
|
|
|
data/org.freedesktop.NetworkManager.policy.in.in
|
2019-04-15 06:16:00 +00:00
|
|
|
shared/nm-glib-aux/nm-shared-utils.c
|
2020-12-30 16:32:10 +00:00
|
|
|
shared/nm-log-core/nm-logging.c
|
all: move "src/" directory to "src/core/"
Currently "src/" mostly contains the source code of the daemon.
I say mostly, because that is not true, there are also the device,
settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
helper, and probably more.
Also we have source code under libnm-core/, libnm/, clients/, and
shared/ directories. That is all confusing.
We should have one "src" directory, that contains subdirectories. Those
subdirectories should contain individual parts (libraries or
applications), that possibly have dependencies on other subdirectories.
There should be a flat hierarchy of directories under src/, which
contains individual modules.
As the name "src/" is already taken, that prevents any sensible
restructuring of the code.
As a first step, move "src/" to "src/core/". This gives space to
reorganize the code better by moving individual components into "src/".
For inspiration, look at systemd's "src/" directory.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743
2021-02-03 14:25:56 +00:00
|
|
|
src/core/NetworkManagerUtils.c
|
|
|
|
|
src/core/main.c
|
|
|
|
|
src/core/main-utils.c
|
|
|
|
|
src/core/dhcp/nm-dhcp-dhclient.c
|
|
|
|
|
src/core/dhcp/nm-dhcp-dhclient-utils.c
|
|
|
|
|
src/core/dhcp/nm-dhcp-manager.c
|
|
|
|
|
src/core/dns/nm-dns-manager.c
|
|
|
|
|
src/core/devices/adsl/nm-device-adsl.c
|
|
|
|
|
src/core/devices/bluetooth/nm-bluez-manager.c
|
|
|
|
|
src/core/devices/bluetooth/nm-device-bt.c
|
|
|
|
|
src/core/devices/nm-device-6lowpan.c
|
|
|
|
|
src/core/devices/nm-device-bond.c
|
|
|
|
|
src/core/devices/nm-device-bridge.c
|
|
|
|
|
src/core/devices/nm-device-dummy.c
|
|
|
|
|
src/core/devices/nm-device-ethernet.c
|
|
|
|
|
src/core/devices/nm-device-ethernet-utils.c
|
|
|
|
|
src/core/devices/nm-device-infiniband.c
|
|
|
|
|
src/core/devices/nm-device-ip-tunnel.c
|
|
|
|
|
src/core/devices/nm-device-macvlan.c
|
|
|
|
|
src/core/devices/nm-device-tun.c
|
|
|
|
|
src/core/devices/nm-device-veth.c
|
|
|
|
|
src/core/devices/nm-device-vlan.c
|
|
|
|
|
src/core/devices/nm-device-vrf.c
|
|
|
|
|
src/core/devices/nm-device-vxlan.c
|
|
|
|
|
src/core/devices/nm-device-wpan.c
|
|
|
|
|
src/core/devices/team/nm-device-team.c
|
|
|
|
|
src/core/devices/wifi/nm-device-olpc-mesh.c
|
|
|
|
|
src/core/devices/wifi/nm-device-wifi.c
|
|
|
|
|
src/core/devices/wifi/nm-wifi-utils.c
|
|
|
|
|
src/core/devices/wwan/nm-modem-broadband.c
|
|
|
|
|
src/core/nm-config.c
|
|
|
|
|
src/core/nm-iface-helper.c
|
|
|
|
|
src/core/nm-manager.c
|
|
|
|
|
src/core/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c
|
|
|
|
|
src/core/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh.c
|