Re: [PATCH 3/4] devices/wifi: Add the wifi-backend config option

On Wed, 2017-12-06 at 00:41 +0100, Andrew Zaborowski wrote:
Hi Dan,

On 5 December 2017 at 17:47, Dan Williams <dcbw redhat com> wrote:
On Tue, 2017-12-05 at 16:26 +0100, Andrew Zaborowski wrote:
Let the config file select between creating classes of
(for the usual wpa_supplicant based devices) and NMDeviceIwd
on the new NetworkManager.conf setting.

This seems wrong to me.  We usually try to keep things runtime
rather than add config options like this.  Is there any reason you
would have both wpa_supplicant and iwd running on the same system
the same time?

No, you'd want to avoid that for wifi devices.  That's why I think
even separate (conflicting) plugins would be fine in this case but
not sure if this is possible with NM's current plugin system.

Conflicting plugins would be a possibility, but as the name
NetworkManager-wifi is already taken, there is no good name left.

Also, I think there is an advantage of having one plugin support both
backends. It makes it much easier for distributions to support both
supplicant and iwd.

But I also think that the backend cannot be detected reliably. So, a
configuration option seems necessary to force a backend (possibly to
overrule autodetection).

Maybe the documentation should not say: 
<literal>wpa_supplicant</literal> is also the default backend.
but instead: "if the setting is missing, it is autodetected.".

-- although for now, it means to always ~detect~ supplicant.

Would it ever make sense that one device is managed by supplicant and
another by iwd? I think it would. Maybe this should hence be configured


the [device] section allows to configure settings per-device, like




We currently lookup such configuration via
nm_config_data_get_device_config(). But inside the device-factory you
don't have a NMDevice instance at hand, to make that decision. We would
need a new "nm_config_data_get_device_config_by_ifindex()", to get the
matching parameters from NMPlatform.

We can do this later -- but before 1.12.0 release.

Could we check whether the iwd dbus service is claimed
and just use iwd if it's running?

We could do that but it'd rely on iwd running before NetworkManager
starts, maybe that's not an issue.  I seem to remember a DBus design
guideline according to which clients should tolerate services coming
up and going away.

Best regards
networkmanager-list mailing list
networkmanager-list gnome org

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]