We use clang-format for automatic formatting of our source files.
Since clang-format is actively maintained software, the actual
formatting depends on the used version of clang-format. That is
unfortunate and painful, but really unavoidable unless clang-format
would be strictly bug-compatible.
So the version that we must use is from the current Fedora release, which
is also tested by our gitlab-ci. Previously, we were using Fedora 34 with
clang-tools-extra-12.0.1-1.fc34.x86_64.
As Fedora 35 comes along, we need to update our formatting as Fedora 35
comes with version "13.0.0~rc1-1.fc35".
An alternative would be to freeze on version 12, but that has different
problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it
would be cumbersome for our developers which are on Fedora 35 to use a
clang that they cannot easily install).
The (differently painful) solution is to reformat from time to time, as we
switch to a new Fedora (and thus clang) version.
Usually we would expect that such a reformatting brings minor changes.
But this time, the changes are huge. That is mentioned in the release
notes [1] as
Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353)
[1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
The previous implementation did some ratelimiting, namely how many parallel
ActivateConnection D-Bus calls are in fly. This way we are able to kick off
many parallel calls, but the activations themselves were not ratelimited.
Rework the code. Now there are two rate limits (that can be set via environment
variables):
NUM_PARALLEL_STARTING
NUM_PARALLEL_IN_PROGRESS
This allows more control about how much is happening in parallel. If we are
going to activate 1000 profiles, then it matters that we do things in parallel,
but not everything at the same time.
It's an example for how to use libnm and asynchronous API.
But it's also a script I will use to test activating many
profiles in parallel.
Also add a test script that creates many veth interfaces and connection
profiles. So now you can do:
sudo NUM_DEVS=100 contrib/scripts/test-create-many-device-setup.sh setup
./examples/python/gi/nm-up-many.py c-a{1..100}
and cleanup with
nmcli connection down c-a{1..100}
sudo contrib/scripts/test-create-many-device-setup.sh cleanup
Of course, be careful to do this on your production machine.
First of all, the "os.setuid()" call is never reached. lgtm.com warns about
that, and warnings are annoying because they require investigation.
This code is only in the example, so that the user would understand that
they should edit the source and set the desired UID. But you can only
call setuid() if you have CAP_SETUID, so commonly this anyway doesn't
work -- unless you are root already, and then you actually don't need
it either.
Let's drop this code from the example.
Maybe this example really should be dropped. Does the "dbus" python
module even still work? Doesn't for me...
input() in Python2 evaluated the string and was thus unsafe. On
Python2, the right choice is raw_input. In Python3, input does
what raw_input did.
Work around this.
The main "problem" is that lgtm.com flags this as error. The fix
in the example is not important, but getting a low number of warnings
is.
- add more error handling and free/unref data.
- split code in 3 functions: vpn_connection_import(),
connection_add() and main(). These steps are mostly
independent, and having them in separate functions
makes their separation clearer.
- handle error from nm_client_add_connection_async() to
exit program with non zero exit code.
../examples/C/glib/vpn-import-libnm.c: In function main:
../examples/C/glib/vpn-import-libnm.c:72:1: error: control reaches end of non-void function [-Werror=return-type]
}
^
Fixes: 905f9975d2 ('example: importing vpn with libnm')
"libnm-core/" is rather complicated. It provides a static library that
is linked into libnm.so and NetworkManager. It also contains public
headers (like "nm-setting.h") which are part of public libnm API.
Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which
only rely on public API of libnm-core, but are themself static
libraries that can be used by anybody who uses libnm-core. And
"libnm-core/nm-libnm-core-intern" is used by libnm-core itself.
Move "libnm-core/" to "src/". But also split it in different
directories so that they have a clearer purpose.
The goal is to have a flat directory hierarchy. The "src/libnm-core*/"
directories correspond to the different modules (static libraries and set
of headers that we have). We have different kinds of such modules because
of how we combine various code together. The directory layout now reflects
this.
Fedora 33's version of python-black is the authoritative version we
use for formatting -- note that formatting may look different depending
on the black version.
Recently, the package was updated to 20.8~b1-1.fc33, which treats
these lines different.
Work around that by adjusting the code so that both older and current
versions of python black behave the same.
The python example is (also) used to test the feature. That is because
currently nmcli does not yet have support for ovs.external-ids and this
API is only accessible via D-Bus (or a tool like this example).
And example script for getting and setting OVS external-ids.
Since currently there is no nmcli support for these properties yet,
the script becomes more interesting.
This "example" is rather long, and it showcases less the usage of
libnm (which is rather trivial, with respect to configuring
NMSettingOvsExternalIDs). Instead, it aims to provide a useful
command line tool for debugging. Hence, it's mostly concerned with
an elaborate command line syntax and useful print output.
Run:
./contrib/scripts/nm-code-format.sh -i
./contrib/scripts/nm-code-format.sh -i
Yes, it needs to run twice because the first run doesn't yet produce the
final result.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
The script is run for every dispatcher event. Most of the events are not
actually relevant, and we just need to determine that there is nothing
to do and quit.
Avoid calling "dirname" and "basename".
The supported ifcfg-file has a very specific form. We can just check
(and parse) it in one got regular expression in bash.
A shell script is executed line-by-line. Note that for most dispatcher
events, "10-ifcfg-rh-routes.sh" has nothing to do and will just quit.
Move those checks earlier, to avoid bash executing the code that won't
be needed most of the time.
Qt dependencies have been moved to the main build file where the
rest of dependencies are located. This makes it easier to find them.
The included directories has also reviewed and removed the
unnecessary ones.
