[PATCH BlueZ v1] transport: Attempt to reuse object paths whenever possible

[PATCH BlueZ v1] transport: Attempt to reuse object paths whenever possible

[Luiz Augusto von Dentz]

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

This attempts to reuse object paths whenever possible to make
scripting a little more predictable by not having the fd number
being increased regardless of the actual number of transports.
---
 profiles/audio/transport.c | 33 ++++++++++++++++++++++++++-------
 1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/profiles/audio/transport.c b/profiles/audio/transport.c
index bc550b743981..83e3c9791a66 100644
--- a/profiles/audio/transport.c
+++ b/profiles/audio/transport.c
@@ -2582,7 +2582,7 @@ struct media_transport *media_transport_create(struct btd_device *device,
 	struct media_endpoint *endpoint = data;
 	struct media_transport *transport;
 	const struct media_transport_ops *ops;
-	static int fd = 0;
+	int fd;
 
 	transport = g_new0(struct media_transport, 1);
 	if (device)
@@ -2595,15 +2595,34 @@ struct media_transport *media_transport_create(struct btd_device *device,
 	transport->size = size;
 	transport->remote_endpoint = g_strdup(remote_endpoint);
 
-	if (device)
-		transport->path = g_strdup_printf("%s/fd%d",
+	for (fd = g_slist_length(transports); fd < UINT8_MAX; fd++) {
+		char *path;
+
+		if (device)
+			path = g_strdup_printf("%s/fd%d",
 					remote_endpoint ? remote_endpoint :
-					device_get_path(device), fd++);
-	else
-		transport->path = g_strdup_printf("%s/fd%d",
+					device_get_path(device),
+					fd);
+		else
+			path = g_strdup_printf("%s/fd%d",
 					remote_endpoint ? remote_endpoint :
 					adapter_get_path(transport->adapter),
-					fd++);
+					fd);
+
+		/* Check if transport already exists */
+		if (!find_transport_by_path(path)) {
+			transport->path = path;
+			break;
+		}
+
+		g_free(path);
+	}
+
+	if (!transport->path) {
+		error("Unable to allocate transport path");
+		goto fail;
+	}
+
 	transport->fd = -1;
 
 	ops = media_transport_find_ops(media_endpoint_get_uuid(endpoint));
-- 
2.51.0

RE: [BlueZ,v1] transport: Attempt to reuse object paths whenever possible

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1011517

---Test result---

Test Summary:
CheckPatch                    PENDING   0.39 seconds
GitLint                       PENDING   0.37 seconds
BuildEll                      PASS      20.09 seconds
BluezMake                     PASS      2691.70 seconds
MakeCheck                     PASS      19.76 seconds
MakeDistcheck                 PASS      185.60 seconds
CheckValgrind                 PASS      236.80 seconds
CheckSmatch                   PASS      308.80 seconds
bluezmakeextell               PASS      128.20 seconds
IncrementalBuild              PENDING   0.34 seconds
ScanBuild                     PASS      911.17 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH BlueZ v1] transport: Attempt to reuse object paths whenever possible

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Tue, 14 Oct 2025 16:25:51 -0400 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> 
> This attempts to reuse object paths whenever possible to make
> scripting a little more predictable by not having the fd number
> being increased regardless of the actual number of transports.
> ---
>  profiles/audio/transport.c | 33 ++++++++++++++++++++++++++-------
>  1 file changed, 26 insertions(+), 7 deletions(-)

Here is the summary with links:
  - [BlueZ,v1] transport: Attempt to reuse object paths whenever possible
    https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=dacb93ddc1b9

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH BlueZ v1] transport: Attempt to reuse object paths whenever possible

[Pauli Virtanen]

Hi,

ti, 2025-10-14 kello 16:25 -0400, Luiz Augusto von Dentz kirjoitti:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> 
> This attempts to reuse object paths whenever possible to make
> scripting a little more predictable by not having the fd number
> being increased regardless of the actual number of transports.

This design adds possible race conditions, of the type:

BlueZ> remove transport /.../fd123
BlueZ> add transport  /.../fd123
Client> ClearConfiguration /.../fd123
Client> receive DBus message that /.../fd123 was removed
Client> receive DBus message that /.../fd123 was added
Client> receive DBus message that /.../fd123 was removed

so the client deleted the wrong transport (or made some other operation
on the wrong object).

AFAICS, there's no way around this race except unique ids.

From experience: Pipewire reuses object ids in a similar way.
Ultimately, the race conditions were too bad, and we had to attach
separate generation IDs to make the IDs unique. Luckily there was room
in the wire protocol so it could be hid there as an implementation
detail.

I looked at libdbus sources and couldn't see it has a race protection
like that, so it seems to me there's none and it's up to applications.

So I think it's better to keep using unique object paths.

For scripting, bluetoothctl maybe could have some special notation for
matching transports by glob or some "n-th since script start" notation.

> ---
>  profiles/audio/transport.c | 33 ++++++++++++++++++++++++++-------
>  1 file changed, 26 insertions(+), 7 deletions(-)
> 
> diff --git a/profiles/audio/transport.c b/profiles/audio/transport.c
> index bc550b743981..83e3c9791a66 100644
> --- a/profiles/audio/transport.c
> +++ b/profiles/audio/transport.c
> @@ -2582,7 +2582,7 @@ struct media_transport *media_transport_create(struct btd_device *device,
>  	struct media_endpoint *endpoint = data;
>  	struct media_transport *transport;
>  	const struct media_transport_ops *ops;
> -	static int fd = 0;
> +	int fd;
>  
>  	transport = g_new0(struct media_transport, 1);
>  	if (device)
> @@ -2595,15 +2595,34 @@ struct media_transport *media_transport_create(struct btd_device *device,
>  	transport->size = size;
>  	transport->remote_endpoint = g_strdup(remote_endpoint);
>  
> -	if (device)
> -		transport->path = g_strdup_printf("%s/fd%d",
> +	for (fd = g_slist_length(transports); fd < UINT8_MAX; fd++) {
> +		char *path;
> +
> +		if (device)
> +			path = g_strdup_printf("%s/fd%d",
>  					remote_endpoint ? remote_endpoint :
> -					device_get_path(device), fd++);
> -	else
> -		transport->path = g_strdup_printf("%s/fd%d",
> +					device_get_path(device),
> +					fd);
> +		else
> +			path = g_strdup_printf("%s/fd%d",
>  					remote_endpoint ? remote_endpoint :
>  					adapter_get_path(transport->adapter),
> -					fd++);
> +					fd);
> +
> +		/* Check if transport already exists */
> +		if (!find_transport_by_path(path)) {
> +			transport->path = path;
> +			break;
> +		}
> +
> +		g_free(path);
> +	}
> +
> +	if (!transport->path) {
> +		error("Unable to allocate transport path");
> +		goto fail;
> +	}
> +
>  	transport->fd = -1;
>  
>  	ops = media_transport_find_ops(media_endpoint_get_uuid(endpoint));

-- 
Pauli Virtanen