1) the command line gets shorter. I frequently run `make V=1` to see
the command line arguments for the compiler, and there is a lot
of noise.
2) define each of these variables at one place. This makes it easy
to verify that for all compilation units, a particular
define has the same value. Previously that was not obvious or
even not the case (see commit e5d1a71396
and commit d63cf1ef2f).
The point is to avoid redundancy.
3) not all compilation units need all defines. In fact, most modules
would only need a few of these defines. We aimed to pass the necessary
minium of defines to each compilation unit, but that was non-obvious
to get right and often we set a define that wasn't used. See for example
"src_settings_plugins_ibft_cppflags" which needlessly had "-DSYSCONFDIR".
This question is now entirely avoided by just defining all variables in
a header. We don't care to find the minimum, because every component
gets anyway all defines from the header.
4) this also avoids the situation, where a module that previously did
not use a particular define gets modified to require it. Previously,
that would have required to identify the missing define, and add
it to the CFLAGS of the complation unit. Since every compilation
now includes "config-extra.h", all defines are available everywhere.
5) the fact that each define is now available in all compilation units
could be perceived as a downside. But it isn't, because these defines
should have a unique name and one specific value. Defining the same
name with different values, or refer to the same value by different
names is a bug, not a desirable feature. Since these defines should
be unique accross the entire tree, there is no problem in providing
them to every compilation unit.
6) the reason why we generate "config-extra.h" this way, instead of using
AC_DEFINE() in configure.ac, is due to the particular handling of
autoconf for directory variables. See [1].
With meson, it would be trivial to put them into "config.h.meson".
While that is not easy with autoconf, the "config-extra.h" workaround
seems still preferable to me.
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Installation-Directory-Variables.html
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[@]}"
$ nmcli c add type ovs-port ifname ovsport0
Error: Failed to add 'ovs-port-ovsport0' connection: connection.type:
Only 'ovs-port' connections can be enslaved to 'ovs-bridge'
nm_streq0() is not good here. It fails (with a wrong error message) even
when the slave_type is not set, which it shouldn't since slave_type can
be normalized. The real problem is the lack of the master property.
This fixes the condition:
$ nmcli c add type ovs-port ifname ovsport0
Error: Failed to add 'ovs-port-ovsport0' connection: connection.master:
A connection with a 'ovs-port' setting must have a master.
Corrects the error message:
$ nmcli c add con-name br0 type bridge
$ nmcli c add type ovs-port ifname ovsport0 parent br0
Error: Failed to add 'bridge-slave-ovsport0' connection: connection.slave-type:
'ovs-port' connections must be enslaved to 'ovs-bridge', not 'bridge'
And gets rid of a confusing nm_streq0 use when comparing the type, since
at that point type must not be NULL anymore.
Fixes: 4199c976da
gretap and ip6gretap ip-tunnel interfaces encapsulate L2 packets over
IP. Allow adding a wired setting for such connections so that users
can change the interface MAC.
Although we don't really need protect for thread safety in _nm_utils_init(),
avoid using static variables without lock/atomic operations. libnm is not
thread-safe, but we still should try to avoid potential issues whenever it is
easy.
constructor functions are ugly, because code is running before
main() starts. Instead, as the registration code for NMSetting types
is insid the GType constructor, we just need to ensure at the
right place, that the GType was created.
The right place here is _register_settings_ensure_inited(), because
that is called before we need the registration information.
_nm_register_setting() and _nm_register_setting_impl() are called from within
the GType constructor for the NMSetting subtype. As such, at that point it
runs inside a g_once_init_enter() block. However, each implementation
for initializing the GType has a separate g_once_init_enter() variable, hence,
if two threads create GType instances for different NMSetting subclasses, there
is a race.
libnm is not thread safe. However, it should be at least thread safe
with respect to constructing the GType instances.
For NMSetting subtypes, we need the static dictionaries "registered_settings" and
"registered_settings_by_type" to keep track of existing NMSetting types.
Initialize these dictionaries inside NMSetting's type initialization code.
This is guaranteed to run before any use of NMSetting type, and is also
guarded by a mutex.
Also, drop the __attribute__((constructor)) function to initialize the
hash tables. They are not needed, and it's ugly to run code before
main().
Add support for a new wireguard link type to the platform code. For now
this only covers querying existing links via genetlink and parsing them
into platform objects.
It's for 6LoWPAN devices. "o.fd.NM.Device.6Lowpan" wouldn't be a valid
interface name -- just skip the leading numeral, that's what kernel also
does on similiar occassions.
For some device types it's not going to be sufficient to tell whether
they carry "IP".
In particular, there's no way to carry legacy IP over the tiny MTU
datagrams of IEEE 802.15.4 WPAN links while an IPv6 transport exist
in form of 6LoWPAN.
A configuration with duplicate tc qdiscs and tfilters is not valid;
reject it in verify(). Note that nm_setting_tc_config_add_qdisc() and
nm_setting_tc_config_add_tfilter() can't add duplicate entries and so
the only way to achieve an invalid configuration is setting the
properties directly.
https://github.com/NetworkManager/NetworkManager/pull/95
When link auto-negotiation is enabled, by default the network device
advertises all the supported speed and duplex modes in order to
negotiate the fastest link speed with the remote endpoint.
It is possible anyway to configure the device to just advertise and
accept a subset of supported modes.
This could be useful to properly enforce gigabit speeds on Ethernet:
as stated in IEEE 802.3 specification, auto-negotiation is mandatory
for 1000Base-T and 10GBase-T standards.
Allow specific values to 802-3-ethernet.speed and 802-3-ethernet.duplex
properties also when 802-3-ethernet.auto-negotiate=yes: this will
result in link auto-negotiation advertising the specified speed/duplex
mode as the only one available.
It is safer to enable send-sci by default because, at the cost of
8-byte overhead, it makes MACsec work over bridges (note that kernel
also enables it by default). While at it, also make the option
configurable.
https://bugzilla.redhat.com/show_bug.cgi?id=1588041
In a lot of cases, we don't require the GBytes out-argument. This
is the case when called from NMSettingIP6Config's verify().
Avoid allocating the GBytes instance and also don't heap allocate
the temporary buffer in that case.
Also, being called from NMSettingIP6Config's verify(), at which
point the string value contains untrusted data. Of course, we
do very badly in general protecting against the user creating
huge settings, which could trick NetworkManage to allocate
large amounts of memory (and being killed by glib's out of memory
handling). We should handle such cases better in general, but
just avoid it here.
Since we know that the buffer must hold at most 128+2 bytes,
we can stack allocate it. Later, in case we really need to
return the value, we can create a GBytes instance of the right
size.
allow to specify the DUID to be used int the DHCPv6 client identifier
option: the dhcp-duid property accepts either a hex string or the
special values "lease", "llt", "ll", "stable-llt", "stable-ll" and
"stable-uuid".
"lease": give priority to the DUID available in the lease file if any,
otherwise fallback to a global default dependant on the dhcp
client used. This is the default and reflects how the DUID
was managed previously.
"ll": enforce generation and use of LL type DUID based on the current
hardware address.
"llt": enforce generation and use of LLT type DUID based on the current
hardware address and a stable time field.
"stable-ll": enforce generation and use of LL type DUID based on a
link layer address derived from the stable id.
"stable-llt": enforce generation and use of LLT type DUID based on
a link layer address and a timestamp both derived from the
stable id.
"stable-uuid": enforce generation and use of a UUID type DUID based on a
uuid generated from the stable id.
The files in shared/nm-utils are not compiled as one static library,
instead each subproject that needs (parts of) them, re-compiles the
files individually.
The major reason for that is, because we might have different compile
flags, depending on whether we build libnm-core or
libnm-util/libnm-glib. Actually, I think that is not really the case,
and maybe this should be refactored, to indeed build them all as a
static library first.
Anyway, libnm-util, libnm-glib, clients' common lib, they all need a
different set of shared files that they should compile. Refactor
"shared/meson.build" to account for that and handle it like autotools
does.
Another change is, that "shared_c_siphash_dep" no longer advertises
"include_directories: include_directories('c-siphash/src')". We don't
put c-siphash.h into the include search path. Users who need it, should
include it via "#include <c-siphash/src/c-siphash.h>". The only exception
is when building shared_n_acd library, which is not under our control.
Originally, we used "nm-utils/siphash24.c", which was copied
from systemd's source tree. It was both used by our own NetworkManager
code, and by our internal systemd fork.
Then, we added "shared/c-siphash" as a dependency for n-acd.
Now, drop systemd's implementation and use c-siphash also
for our internal purpose. Also, let systemd code use c-siphash,
by patching "src/systemd/src/basic/siphash24.h".
Use two common defines NM_BUILD_SRCDIR and NM_BUILD_BUILDDIR
for specifying the location of srcdir and builddir.
Note that this is only relevant for tests, as they expect
a certain layout of the directories, to find files that concern
them.
