The NmCli structure is passed around everywhere and contains all
the state of the program. It is very hard to follow which parts
are used where.
Split out more configuration options to a NmcConfig field. This field
is mostly immutable, and modified at particular places that now can be
easily found.
nmc contains all options and collects output data. It is very hard to
understand what it does. Start splitting it up, and pass arguments along
-- as needed.
Otherwise, changing the structure is difficult because it all depends
on the order (and you don't immdiately see which field is used where).
Also, drop the name_l10n field.
libnm contains the public function nm_utils_enum_from_str() et al.
The function is not flexible enough for nmcli's usecase. So, I would
need another public function like nm_utils_enum_from_str_full() that
has an extended API.
That was already required previously for ifcfg-rh writer, but in that
case I could just add it as internal API as libnm-core is linked statically
with NetworkManager.
I don't want to commit to a public API for an utility function. So move
the code instead to the shared directory, so that nmcli may link
statically against it and use the internal API.
These functions are only used by nm-meta-setting-desc.c. Make them internal.
Unfortunately, they are part of "common.h" which cannot be used without
the rest of nmcli. Still todo.
This part contains static functions and variables to describe
settings. It is distinct from the mechanism to use them, or
access them.
Split it out.
It still uses clients/cli/common.h and clients/cli/utils.h
which shall be fixed next.
They will be moved out of nmcli as they are generally useful.
Even if they happen to be used only inside nmcli, there should
be a better separation between logic (nmcli) and setting decriptions.
Mostly these strings are static. In same cases they are generated
however. Instead of caching them in a static variable, return them
to the caller.
And belatedly fix invoking describe_fcn().
settings.c basically consists of property-type structures and *a lot* of
accessors. All these accessors share the same argument list.
It is very repetitive to specify it over and over again. Also, there
are so many arguments that one is compelled to wrap the lines. All
in all it results in a lot of noise that takes the eye from the important
code.
Also, the argument list is expected to change, so we possibly only
have to change one place.
We shall not only have a PropertyInfo. Most properties share common
behavior, that is, they have a type. Move the function pointers to
a NmcPropertyType structure, so that it can be reused for multiple
properties.
This promotes the idea that properties have a (limited) set of types
with some type specific behaviors. Contrary, to having each property
re-implement fully it's type. E.g. instead of having various property
re-define their full behavior as an "bool", have one property type
"bool" which can be attached to a property.
Add an improved way of tracking meta data about settings.
E.g. it is wrong to generate for each property a nmc_property_*_get_*()
function. Instead, there should be a meta data about the property
itself, and a mechanism to retrieve the property.
For now, only do this for NMSettingConnection and keep all the existing
infrastructure in place. Later on all settings shall be moved.
Especially to accomodate NmcOutputField mangles the concept of
setting-meta data, formatting options, and collecting output results.
It's a total hack, that will be need fixing later.
This will be solved differently by th/setting-user-data-bgo776276
branch. Revert the change for now, the same functionality will be
restored later.
This reverts commit 623d888801.
nm_utils_enum_to_str() may also output numeric values if there is no
corresponding "nick" for the enum/flag value.
For enums the value is in decimal and for flags the value is hexadecimal
(with a "0x" prefix).
The same was already supported by nm_utils_enum_from_str() when reading
the value. However, previously, reading a flag would only support hex
numbers and reading a enum would only support decimal numbers.
Extend that, to allow passing numbers in any base. For nm_utils_enum_to_str()
also make sure to never output nicks that may be misinterpreted as
numbers.
It is not uncommon that a flags type has also the value 0 mapped,
for example to "unknown" or "none".
In that case, we should not return an empty string, but instead
that zero value.
Also, flags actually have an unsigned type. That isn't a real
problem to cast it to a signed int. But be more careful about
it and use unsigned while handling unsigned values and only
cast to int once.
Commit 029a0a21ea ("device: split out cloned MAC decision from
nm_device_hw_addr_set_cloned()") accidentally removed the assignment
of the new device @hw_addr_type, which then was left to
HW_ADDR_TYPE_UNSET. As a consequence, we never restored the initial
MAC address when the connection was deactivated. Fix this.
Fixes: 029a0a21ea
