On Fri, 2013-08-16 at 18:32 +0300, Tanu Kaskinen wrote:
> On Tue, 2013-08-13 at 01:54 -0300, jprvita at gmail.com wrote:
> > static void device_free(pa_bluetooth_device *d) {
> > + unsigned i;
> > +
> > pa_assert(d);
> >
> > + for (i = 0; i < PA_BLUETOOTH_PROFILE_COUNT; i++) {
> > + pa_bluetooth_transport *t;
> > +
> > + if (!(t = d->transports[i]))
> > + continue;
> > +
> > + d->transports[i] = NULL;
> > + transport_state_changed(t, PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED);
> > + /* TODO: check if there is no risk of calling
> > + * transport_connection_changed_cb() when the transport is already freed */
> > + pa_bluetooth_transport_free(t);
>
> IMO pa_bluetooth_transport_free() should be called by the transport
> code, because the backend also creates the transport. The backend may
> need a callback for getting notified about the device going away. Or
> perhaps there should be pa_bluetooth_transport_kill(), with a kill()
> callback in the backend. This would be similar to how sink inputs are
> killed if the sink they're connected to goes away.
>
> If the backend is responsible for calling pa_bluetooth_transport_free(),
> the core should still ensure that t->device is set to NULL and that the
> transport is removed from discovery->transports (feel free to create
> pa_bluetooth_transport_unlink() for this purpose, if you want).
I'll add that it would be good to have the bluez transport backend in a
separate file, so that there would be clear separation with the
"bluetooth core" code and the transport backends.
--
Tanu
