bluetooth: settings: Make BT name persistance an option

[spanceac]

The device's BT name can be set/changed using API call bt_set_name() when CONFIG_BT_DEVICE_NAME_DYNAMIC is enabled. If BT settings are also enabled, the BT name set through the above mentioned API call will also be stored peristently in the settings partition. Then at each boot, the name setting is restored and set as BT name.

This behavior of automatically setting the BT name at each boot from a value that was set in a previous boot is not be desired by all API users.

This commit introduces CONFIG_BT_SETTINGS_BT_NAME_STORE configuration option that gives the user the option to choose if it wants to restore the BT name from persistent memory.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Thalley]

@spanceac This feature seems counterintuitive to me. Can you provide use case for it?

[spanceac]

@Thalley we are building products that we want to start advertising always with the same BT name, but to also have the capability to change that name dynamically, if we wish.

We don't want the name that we set dynamically to persist between reboots. It was actually a surprise that the BT name used in advertising after a reboot was the one that we dynamically set in a previous session. We enabled BT settings config just to have bonds and we didn't expected this side effect

[spanceac]

I forgot to mention, the BT name that we want to have at each reboot is the one set in CONFIG_BT_DEVICE_NAME

[Thalley]

It was actually a surprise that the BT name used in advertising after a reboot was the one that we dynamically set in a previous session

Unless you are using an older version of Zephyr, the advertised name is specifically set by the application, and does not rely on the actual BT device name (although you definitely should use the actual BT device name)

I forgot to mention, the BT name that we want to have at each reboot is the one set in CONFIG_BT_DEVICE_NAME

Seems like you could just call bt_set_name(CONFIG_BT_DEVICE_NAME) on reboot then :)

The reason why I'm pushing back on this, is that it adds a small additional layer of complexity in the OS that needs to be maintained, without actually providing new functionality. I also expect your use case to be quite unique. Coincidentally I've also recently created #93769 as I don't think it makes sense to have both a compile-time CONFIG_BT_DEVICE_NAME name and a dynamic runtime name

[spanceac]

the problem with calling bt_set_name(CONFIG_BT_DEVICE_NAME) at each start-up is that it might be in a race condition with the BT settings subsystem. Call bt_set_name(CONFIG_BT_DEVICE_NAME) too early and your name will get overriden by the BT settings

[Thalley]

the problem with calling bt_set_name(CONFIG_BT_DEVICE_NAME) at each start-up is that it might be in a race condition with the BT settings subsystem. Call bt_set_name(CONFIG_BT_DEVICE_NAME) too early and your name will get overriden by the BT settings

Now that sounds like an issue :) Doing

bt_enable(NULL);
settings_load();
bt_set_name(CONFIG_BT_DEVICE_NAME);

in your main function should always work. If that doesn't work, then I think there's something we need to look into

[spanceac]

Our use case is a little bit more complicated and it would have been solved by this PR. But I understand that you're reluctant to merge it. I will see what workaround I can find starting from your proposed solution

[alwa-nordic]

I am for making our stack flexible and I think storing the GAP Device Name in settings should be an optional feature.

I have created a discussion about improvements to the GAP Device Name and Appearance APIs.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.