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.
Calling nl_recvmsgs_default() leads dirctly to recvmsgs() from
"nl.c". This functions reads messages (recvmsg) in a loop and
invokes the callbacks.
Later we want to merge nlh and nlh_event, meaning that we must
anticipate parsing unrelated messages while waiting for an ACK.
While that would be possible by registering different callbacks
and letting them interact, it is actually more complicated. Just
assume full control over the message parsing.
Basically, copy recvmsgs() to event_handler_recvmsg(). For now just
copy the function and do little adjustment (to show the similarity
to the original). Cleanup follows.
Randomly choosing one between the two link creation methods (platform
and external) makes it more difficult to immediately detect when a bug
in introduced. Always execute them using both methods to have a better
code coverage, but still try a third time with a random one to test
different combinations of methods.
Older version of iproute2 fail to add the vxlan (e.g. on Ubuntu 12.04)
Running command: ip link add nm-test-device type vxlan id 42 dev nm-test-parent local 23.1.2.164 group 239.1.2.134 ttl 0 tos 00 dstport 4789 srcport 0 0 ageing 1245
Garbage instead of arguments "id ...". Try "ip link help".
Fallback using only platform.
Strangely on Ubuntu 12.04, when not setting the port range for a vxlan
device, kernel chooses
5: nm-test-device: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default
link/ether 72:09:79:62:9c:45 brd ff:ff:ff:ff:ff:ff promiscuity 0
vxlan id 42 group 239.1.2.134 local 23.1.2.164 dev nm-test-parent srcport 32768 61000 dstport 4789 ageing 1245
The macro EWOULDBLOCK is another name for EAGAIN; they are always the
same in the GNU C Library.
https://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Error-Codes.html
Otherwise, we would need a workaround for EWOULDBLOCK too, because
libnl maps that to NLE_FAILURE. So we would have to detect EAGAIN
as (nle == -NLE_FAILURE && errno == EWOULDBLOCK).
When the errno was accidentally set to EAGAIN or EWOULDBLOCK,
we would only read one single message and return that there is
nothing to read.
This means, if there were more then one messages ready to read,
we would only read the first one and return to the main-loop
(which then again calls back to platform as more data is ready
to be read).
The explainations no longer hold for the most part. Documentation
that is not directly the code is bound the expire.
The code is the best documentation!! :)
With g_return() we try to catch wrong invocations of a function
or passing invalid arguments.
Having ~forgot~ to overwrite a virtual function is such a serious
and fundamental issue, that checking for it at runtime is wasteful
and unnessesary.
If we ever hit such a situation, just crash.
Link related functions should have a "nm_platform_link" prefix. Rename.
Naming is a subjective matter and one might argue that omitting
the "link" part from the name is shorter and even preferred.
However, I think functions related to links should have a common
prefix as the underlyings are strongly related.
Let the link-add functions return the internal pointer to the platform
link object. Similar to link-get, which doesn't copy the link either.
Also adjust the sole users of the add-functions (create-and-realize)
to take the pointer.
Eventually we still copy the returned data, because accessing platform can
invalidate the returned pointer. Thus we don't actually safe any copying
by this (at least every use of the function currently leads to the data
being copied).
Still change it, because I think the API of NMPlatform should look like that.
