This is more for completeness, to go along "nm-code-format.sh"
script.
Usually it's very simple to run black directly (you may still do that).
However, black by default only reformats files with ".py" extension.
So to get all our python files, you'd need to know and explicitly
select them... or use this script.
Also, `black .` scans the entire source tree, and is rather slow.
This script knows which files to select and is thus faster.
When we have a GError* variable on the stack, we usually want to pass
it on to function that can fail. In that case, the variable MUST be
initialized to NULL. This is an easy mistake to make.
Note that this check still can have lots of false positives, for
example, if you have a struct with an GError field. In that case, you
would need to ensure that the entire struct is initialized. Ignore the
warning then.
Also, the check misses if you declare multiple variables on one line.
But that is already discouraged by our style.
There are very few places left where we would accept tabs in a source
file. Warn about that, even if it might cause some false positives.
I think this line was commented out due to a mistake.
The "Ignore-Backport" tag can be used to mark a commit that should not
be backported. Similar to the "cherry picked from" line, which indicates
that the patch was backported.
Anyway, this didn't work correctly, because we first pre-filter the
commits we search (as a performance optimization) by using `git-log` to
get a subset of the commits we want to investigate.
So if you had a commit with an "Ignore-Backport" tag, but without "cherry
picked from" line, then it wasn't found.
Fix that.
Older branches, like "nm-1-32" will always be formatted with a
different, older clang-format version. Luckily we also have on "nm-1-32"
branch the "nm-code-format-container.sh" script, so we can still
reformat the sources using the container.
However, as the name of the container was always "nm-code-format",
we would have to re-generate the container when we switch between
branches. As the container really only depends on the Fedora version
(as the clang-format version is tied to the corresponding Fedora
version), let's include the Fedora version in the name of the container.
We have multiple ways to define properties (like, GVariant based
nm_setting_option_*() or GObject based properties). For the latter,
they nowadays should all be implemented via _nm_setting_property_define_direct_*()
API.
Make checkpatch.pl identify subtree merges in "git am"-formatted
patches and reconstruct the full path names based in the subtree root.
This fixes some spurious warnings for parts of the tree that use
different coding style from what we usually do.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/989
It doesn't actually work inside the root-less container...
Well, it works as far as starting to activate, before it
fails. That is still somewhat useful. So have it there...
The majority of times when I call this script, I want it to do the reformatting,
not the check-only mode. This is also because we use git, so I start with a
clean working directory and run the reformatting code. In the best case, there
is nothing to reformat, and all is good. I seldom want to only check.
Change the default of the script.
"nm-code-format.sh" is going to change the default behavior from "-n" to
"-i", that is, from check-only to reformat. Explicitly pass "-n" where
we want it.
There was always the idea that you could pass paths and filenames
to "nm-code-format.sh" to format only a subset. However, the script
also needs to honor files that should be excluded and don't need
formatting.
Previously, what was implemented via `git ls-files -- ':(exclude)...'`
command, but git-ls-files has a bug ([1]) and might not list all files.
Refactor and do the filtering ourselves.
[1] https://www.spinics.net/lists/git/msg397982.html
The only reason is consistency. The majority of times we
do use g_snprintf(). As there are no strong reasons to
prefer one over the other, prefer the one that use use
most of the time.
g_idle_add() is discouraged, and the checkpatch.pl script warns
about it.
Sometimes there is a legitimate use of it, when you want to always
schedule an idle action (without intent to cancel or track it). That
makes more sense for g_idle_add() than it does for g_timeout_add(),
because a timeout really should be tracked and cancelled if necessary.
Add a wrapper to rename the legitimate uses. This way, we can avoid the
checkpatch.pl warnings, and can grep for the remaining illegitimate uses.
The numeric source IDs exist from a time before 2000, when there
was only one "GMainContext" singleton instance. Nowadays, the source
ID is only relative to one GMainContext, and you'd have to track
that association yourself. Als, g_source_remove() requires an additional
hash lookup, when you could simply track the GSource instance from the
start.
This API should not be used anymore. Operate on GSouce instances
direclty and use API like
nm_clear_g_source_inst()
nm_g_idle_add_source()
nm_g_idle_souce_new()
nm_g_source_attach()
g_source_attach
g_source_destroy
g_source_unref
etc.
Note that if you don't care about to ever remove a source again, like
scheduling an idle action that should not be cancelled, then
g_idle_add(callback, user_data);
is fine. It is only problematic to do something with those numeric IDs.
checkpatch.pl would also flag those uses, but these are just warnings
and in the few cases where such a warning is emitted wrongly, it's find
to ignore them.
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.
