It's anyway a singleton that is still referenced by other components.
So unrefing it in the mainloop does not actually release any memory.
However, the GDBusConnection singleton is fundamental for the run of
the program. Keep it accessible in the global variables.
Note that soon I will drop the GDBusInterfaceSkeleton and only operate
on the GDBusConnection. Then it makes more sense to keep it around.
Note that usually we want to keep the amount of global state small.
But this connection is anyway a singleton (that we already implicitly
use). So, it doesn't change the amount of global state nor does it really
have much state (we either have a reference to the singleton or we don't).
Split command line parsing out of the main() function. For one, it's
an self-contained step, so we can make main() simpler.
Also, we don't need the GOptionEntry on the stack of the main() function
for the remainder of the program.
It's ugly to uncoordinated just call exit(). We should quit the mainloop
and clean up everything we had going.
Note that since Handler has no dispose() function, we also need to hack
a g_signal_handlers_disconnect_by_func(). This will change soon.
Silence messages like
find-scripts: Failed to open dispatcher directory '/usr/lib/NetworkManager/dispatcher.d': Error opening directory “/usr/lib/NetworkManager/dispatcher.d”: No such file or directory
find-scripts: Failed to open dispatcher directory '/usr/lib/NetworkManager/dispatcher.d/pre-up.d': Error opening directory “/usr/lib/NetworkManager/dispatcher.d/pre-up.d”: No such file or directory
The messages about loading the scripts are releated to a particular
request. Hence, they should be logged with that context.
Also, we should avoid using g_log() directly. Use our logging macros
instead.
Previously, we would log several messages with level "debug" / g_info().
_LOG_R_D (request, "start running ordered scripts...");
_LOG_R_D (request, "new request (%u scripts)", request->scripts->len);
_LOG_R_D (request, "completed: no scripts");
Note that this effectively logs a message for every event. I think that
is to verbose and not suitable for regular logging.
Only enable these messages if debug logging is enabled. As such, these debug
level messsages now are enabled together with the trace level messages.
What we currently print as "info" level is too verbose for regular
operation. It prints two messages for every dispatcher event. That's
already for debugging.
Next that will be downgraded, so rename "debug" to "trace" and "info" to
"debug".
There is only renaming, no change in behavior.
"libnm-core" implements common functionality for "NetworkManager" and
"libnm".
Note that clients like "nmcli" cannot access the internal API provided
by "libnm-core". So, if nmcli wants to do something that is also done by
"libnm-core", , "libnm", or "NetworkManager", the code would have to be
duplicated.
Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
Note that:
0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
On the other hand, "libnm-libnm-core-aux.la" is not used by
libnm-core, but provides utilities on top of it.
1) they both extend "libnm-core" with utlities that are not public
API of libnm itself. Maybe part of the code should one day become
public API of libnm. On the other hand, this is code for which
we may not want to commit to a stable interface or which we
don't want to provide as part of the API.
2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
and thus directly available to "libnm" and "NetworkManager".
On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
and "NetworkManager".
Both libraries may be statically linked by libnm clients (like
nmcli).
3) it must only use glib, libnm-glib-aux.la, and the public API
of libnm-core.
This is important: it must not use "libnm-core/nm-core-internal.h"
nor "libnm-core/nm-utils-private.h" so the static library is usable
by nmcli which couldn't access these.
Note that "shared/nm-meta-setting.c" is an entirely different case,
because it behaves differently depending on whether linking against
"libnm-core" or the client programs. As such, this file must be compiled
twice.
(cherry picked from commit af07ed01c0)
For static functions inside a module, the compiler determines on its own
whether to inline the function.
Also, "inline" was used at some places that don't immediatly look like
candidates for inlining. It was most likely a copy&paste error.
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
Coccinelle:
@@
expression a, b;
@@
-a ? a : b
+a ?: b
Applied with:
spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .
With some manual adjustments on spots that Cocci didn't catch for
reasons unknown.
Thanks to the marvelous effort of the GNU compiler developer we can now
spare a couple of bits that could be used for more important things,
like this commit message. Standards commitees yet have to catch up.
We commonly only allow tabs at the beginning of a line, not
afterwards. The reason for this style is so that the code
looks formated right with tabstop=4 and tabstop=8.
Originally, the "callouts" directory contained various programs
that NetworkManager would call, for example the dhcp helper.
For a while, it only contains nm-dispatcher. Thus rename the directory
to indicate that it's for dispatcher.
