Hi Marcel,
* Marcel Holtmann <marcel@xxxxxxxxxxxx> [2011-08-23 09:30:04 -0700]:
> Hi Gustavo,
>
> > > > Disconnect can also be called for connections created with ConnectFD
> > > > ---
> > > > doc/serial-api.txt | 3 +++
> > > > serial/port.c | 14 ++++++++++----
> > > > 2 files changed, 13 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/doc/serial-api.txt b/doc/serial-api.txt
> > > > index 98b0ad4..09a4c0d 100644
> > > > --- a/doc/serial-api.txt
> > > > +++ b/doc/serial-api.txt
> > > > @@ -53,5 +53,8 @@ Methods fd ConnectFD(string pattern) [experimental]
> > > > In that case one of patterns of the Connect method should
> > > > be suplied instead of the TTY device.
> > > >
> > > > + Connection created with Serial.ConnectFD only accept
> > > > + as parameter the same parameters ConnectFD accepts.
> > > > +
> > > > Possible errors: org.bluez.Error.InvalidArguments
> > > > org.bluez.Error.DoesNotExist
> > >
> > > I really fail to see how this is all going to work. We already had this
> > > problem with the PrivateNetwork API in ConnMan. We can not use the fd as
> > > a unique reference.
> >
> > I'm considering that UUID(or channel name, or a friendly name like "sap") is a
> > second reference. You do:
> >
> > Serial.ConnectFD("sap")
> >
> > and then
> >
> > Serial.Disconnect("sap")
>
> does not really work nicely. Once you have two profiles or two of trhe
> same UUIDs this will fail.
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.
But what do you suggest? I think that create a unique ID for each connected
fd can fix this. Serial code would be responsible to assign the UID.
Gustavo
--
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
