Hi Luiz,
> >> >> > This already fails today. Our code doesn't allow us to call twice the Connect
> >> >> > method, so we can't have two of the same UUID connected.
> >> >>
> >> >> Well with RFCOMM you can't really connect multiple times to the same
> >> >> channel/UUID and if we return the same fd clients will probably have
> >> >> conflicts.
> >> >
> >> > you can not connect the same channel twice (except in the other
> >> > direction), that is true, but you can connect to a different channel
> >> > with a different UUID. That is the reason why we also allow connection
> >> > by handles. Or at least we should.
> >>
> >> You mean record handle? Currently we support connecting by UUID,
> >> friendly name or channel.
> >>
> >> > So even if we would make this limitation of 1 connection per UUID, the
> >> > API is a fully asymmetric then. You are suppose to disconnect with the
> >> > result of the connect call. I do not like that at all. It is bad API
> >> > design and we are trying to squeeze this in the wrong way.
> >>
> >> Currently we support disconnecting by UUID, friendly name, channel and
> >> dev node. As you mentioned it doesn't really work for fd since it is
> >> only unique per process, in the other hand the parameter is a pattern.
> >>
> >> Perhaps what we should be doing is to return a object path in
> >> Serial.Connect e.g. [variable
> >> prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/serialXX then Disconnect
> >> just get it as parameter, the drawback is that this does not return
> >> the tty/fd immediately so we need another round-trip or return
> >> multiple values to Connect.
> >
> > I've been discussing this with Johan and we came to two possible solutions.
> > The first one is the similar as this one, with three functions:
> >
> > handle, fd ConnectFD("pattern")
> >
> > ConnectCancel(handle)
> >
> > Disconnect(handle)
> >
> > And other with only ConnectFD() (and maybe ConnectCancel method). Disconnect
> > would be handled by the client with shutdown().
> >
> > I'm tempted to go with this last approach, it's simpler and easier. What do
> > you think?
>
> Yep, I guess the shutdown is the simplest one and I suppose we don't
> have to keep any tracking/reference to the fd in bluetoothd it is up
> to the client process to deal with the connection.
yes, you do have to keep track of the client. You wanna do a proper
shutdown if the client exits unexpectedly. Or forgets to call shutdown.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
