Up to now, the "include" directory contained (only) header files that were
used project-wide by libs, core, clients, et al.
Since the directory now also contains a non-header file, the "include"
name is misleading. Instead of adding yet another directory that is
project-wide, with non-header-only content, rename the "include"
directory to "shared".
The unit tests for libnm and libnm-glib use a NetworkManager stub
service written in Python (test-networkmanager-service.py). As they
share the same server, it makes sense to also share the same utility
code to drive the stub.
Move the common code to include/.
Note that contrary to "nm-test-utils.h", "nm-test-libnm-utils.h" is not
a header-only file. Instead its implementation is in "nm-test-utils-impl.c".
The reason for that this split is, if we later have yet another non-header-only
test-utility, then all the implementations are in "nm-test-utils-impl.c", requiring
the tests to link only one object file.
Parent MAC can be NULL if the interface has gone, fix the following
failed assertion:
[devices/nm-device-vlan.c:107] parent_hwaddr_changed(): (vlan1): parent hardware address changed
nm_device_set_hw_addr: assertion 'addr != NULL' failed
While at it, improve logging by printing the new MAC address.
Fixes: e6d7fee5a6
Make it possible to change ethernet.mtu and
ethernet.cloned-mac-address properties of tun/tap devices
(cloned-mac-address is meaningful only for taps).
Allow calling nm_connection_get_virtual_iface_name() on a non-verified
connection by not asserting asserting against a valid base-setting.
On nma-1-0 branch, nm-applet can crash with:
#3 0x00007ffff2993a7a in g_assertion_message_expr (domain=0x7ffff51fad86 "libnm-util", file=0x7ffff51fb728 "nm-connection.c", line=320, func=0x7ffff51fc028 "_get_type_setting", expr=<optimized out>) at gtestutils.c:2444
#4 0x00007ffff51ac52f in _get_type_setting (connection=0xa3c160 [NMRemoteConnection]) at nm-connection.c:320
#5 0x00007ffff51ac341 in nm_connection_get_virtual_iface_name (connection=0xa3c160 [NMRemoteConnection]) at nm-connection.c:1436
#6 0x0000000000415bdc in add_virtual_items (type=type@entry=0x43c11d "bridge", all_devices=all_devices@entry=0x7f6580, all_connections=all_connections@entry=0x9354a0, menu=menu@entry=0x922990 [GtkMenu], applet=applet@entry=0x6cc000 [NMApplet]) at applet.c:1640
#7 0x00000000004176f6 in nma_menu_add_devices (menu=menu@entry=0x922990 [GtkMenu], applet=applet@entry=0x6cc000 [NMApplet]) at applet.c:1713
#8 0x0000000000418315 in nma_menu_show_cb (menu=0x922990 [GtkMenu], applet=0x6cc000 [NMApplet]) at applet.c:1974
where the connection type is "tun".
Note that libnm accepts invalid connections and exposes them to the
user (albeit issuing a warning). Later on there are many places where
that can lead to further g_return*(), which is ugly indeed.
At least, we should not assert against valid connections (because that
crashes the user) and there is a well known fact that the base setting
will be missing for tun settings. No need to even warn about that in
nm_connection_get_virtual_iface_name() (we already got the warning
during replace_settings).
When adding a very first item for a certain id, don't yet create a
hash table but store the first item inplace. This optimizes storage
for the case where we have only one item for a certain id.
Downsides:
- Add some additional overhead to manage the index
- The NMPCacheId struct grows to 16 bytes, affecting
hashing performance for all object types.
Still do it, based on the assumption that it doesn't matter
for a low number of interfaces. But the O(1) access time matters
when having lots of interfaces.
When deleting an object, we allow failure to delete a non-existing object.
Thus, the only thing we care about is whether the object is no longer
present after deletion. Adjust the return values to reflect that.
The idea was allowing pending delayed-actions and process them in an
idle handler. We dont want to do that, because whenever platform code
returns, we want to have no pending actions -- because otherwise the
platform cache might be in an inconsistent state.
Just drop it.
We would not expect that delayed_action_handle_all() is called recursively.
Assert against that. If we ever happen to call it recursively, we would
need to take care of properly avoiding infinite loops or deep call
stacks.
Track pending netlink requests and properly report the resulting errno
back.
Currently we send only requests in do_request_link() and do_request_all().
These callers don't actually care about the result, all they care that the
request is answered before returning back from platform code to the caller.
Thus, up to now the tracking of the sequence number was pretty simple.
Later we also want to get the errno from a request, thus rework sending
requests to also remember about outstanding sequence numbers and
properly track muliple parallel requests.
Later the synchronous actions (e.g. add-link) will also be handled
via the asynchronous socket.
