The kernel may add a reason for hardware rfkill. Make the NetworkManager
able eto fetch it and parse it.
For now, no action will be taken upon the new reasons.
The different reasons that the kernel can expose are either the radio
was switched off by a hardware rfkill switch. This reason is adveritsed
by bit 0 in the bitmap returned by RFKILL_STATE_REASON udev property.
This is the rfkill that existed until now.
The new reason is mapped to bit 1 and teaches the user space that the
wifi device is currently used by the CSME firmware on the platform. In
that case, the NetworkManager can ask CSME (through the iwlmei kernel
module) what BSSID the CSME firmware is associated to. Once the
NetworkManager gets to the conclusion is has the credentials to connect
to that very same AP, it can request the wifi device and the CSME
firmware will allow the host to take the ownership on the device. CSME
will give 3 seconds to the host to get an IP or it'll take the device
back. In order to complete all the process until we get the DHCP ACK
within 3 seconds, the NetworkManager will need to optimize the scan and
limit the scan to that specific BSSID on that specific channel.
All this flow is not implemented yet, but the first step is to identify
that the device is not owned by the host.
Names in header files should have an "nm" prefix. We do that pretty
consistently. Fix the offenders RfKillState and RfKillType.
Also, rename the RfKillState enums to follow the type name. For example,
NM_RFKILL_STATE_SOFT_BLOCKED instead of RFKILL_SOFT_BLOCKED.
Also, when we camel-case a typedef (NMRfKillState) we would want that
the lower-case names use underscore between the words. So it should be
`nm_rf_kill_state_to_string()`. But that looks awkward. So the right solution
here is to also rename "RfKill" to "Rfkill". That make is consistent
with the spelling of the existing `NMRfkillManager` type and the
`nm-rfkill-manager.h` file.
We don't run glib-mkenums for certain sources like "core" and
"libnm-glib-aux".
These annotations have no effect. Drop them.
They also mess with the automated formatting.
Currently "src/" mostly contains the source code of the daemon.
I say mostly, because that is not true, there are also the device,
settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
helper, and probably more.
Also we have source code under libnm-core/, libnm/, clients/, and
shared/ directories. That is all confusing.
We should have one "src" directory, that contains subdirectories. Those
subdirectories should contain individual parts (libraries or
applications), that possibly have dependencies on other subdirectories.
There should be a flat hierarchy of directories under src/, which
contains individual modules.
As the name "src/" is already taken, that prevents any sensible
restructuring of the code.
As a first step, move "src/" to "src/core/". This gives space to
reorganize the code better by moving individual components into "src/".
For inspiration, look at systemd's "src/" directory.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743