archive mirror
 help / color / mirror / Atom feed
From: Szymon Janc <>
To: Alain Michaud <>,
	Marcel Holtmann <>
Cc: Miao-chen Chou <>,
	Bluetooth Kernel Mailing List  <>,
	Luiz Augusto von Dentz <>,
	Alain Michaud <>,
	Howard Chung <>
Subject: Re: [BlueZ PATCH v2 1/3] error: BR/EDR and LE connection failure reasons
Date: Fri, 23 Jul 2021 10:20:07 +0200	[thread overview]
Message-ID: <2206189.ElGaqSPkdT@ix> (raw)
In-Reply-To: <>


On Friday, 23 July 2021 09:38:40 CEST Marcel Holtmann wrote:

> >>>>> What is the intention to split BR/EDR and LE here. You do know
> >>>>> up-front what connection type you are. Trying to figure out from the
> >>>>> error code what connection you have been trying to establish is plain
> >>>>> wrong.>>>> 
> >>>> In fact the up-front connection type is not necessarily known. In the
> >>>> case of dual-mode devices, such as Bose QC35, a D-Bus client can issue
> >>>> Connect(), and it depends on the timing of connection request (adv
> >>>> usually arrive first compared to inquiry result), it can be either
> >>>> BR/EDR or LE link being established. Another aspect of this is the
> >>>> metrics collection, where knowing transport can be handy. For
> >>>> instance, we can associate the certain error to particular use cases
> >>>> at application layer, and that can help targeting the bottleneck to
> >>>> tackle.
> >>> 
> >>> Then we need to find a different way to convey the transport chosen.
> >>> Doing this by error message is a bad idea.>>> 
> >>>>> The description is that you want to know exactly where the connection
> >>>>> failed. And I think that can be established independent from the
> >>>>> transport.>>>> 
> >>>> Indeed the intention is to know where it failed exactly. However, as
> >>>> mentioned above, transport information is also an important piece of
> >>>> information to know.
> >>> 
> >>> We need to find a different way to inform about which transport failed
> >>> (or better which was chosen in the first place).> 
> > I would love to hear your thoughts on an alternative.  Many of the
> > Apis are transport agnostic (Connect/Pair may end up connecting to
> > either available transports for dual mode devices), but yet the error
> > that results from them are not.  Errors from one transport doesn't
> > make sense for one and vice versa.  A platform wanting to leverage
> > telemetry and metrics to drive ecosystem improvements would ultimately
> > need to know the difference even if the applications may not need to
> > care.
> and we might have made a mistake in the API design and should have given the
> caller more control. We need to review the API design and see if things
> have to change. Just glueing things on at the end makes me suspicious.

Some (5, wow!) years back I've loosely proposed split for org.bluez.Device API 
that was meant to handle some of the dual mode devices issues we've been 
seeing [1] [2]. 

We never got time to fully implement it (mostly due to hacking around device.c 
instead of properly splitting internal implementation into device_le.c and 
device_bredr.c) but got some very initial PoC running.

With new interfaces old Device1 could be simply super-set of two for legacy 
applications purposes.

Maybe such approach is worth re-considering? 


Szymon Janc

  reply	other threads:[~2021-07-23  8:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-26  5:21 [BlueZ PATCH v2 0/3] Detailed error code Miao-chen Chou
2021-06-26  5:21 ` [BlueZ PATCH v2 1/3] error: BR/EDR and LE connection failure reasons Miao-chen Chou
2021-06-26  5:39   ` Marcel Holtmann
2021-07-14 21:08     ` Miao-chen Chou
2021-07-14 22:06       ` Luiz Augusto von Dentz
2021-07-15 23:21         ` Miao-chen Chou
2021-07-16 17:51           ` Luiz Augusto von Dentz
2021-07-19  7:57       ` Marcel Holtmann
2021-07-20 20:57         ` Miao-chen Chou
2021-07-22 20:54           ` Alain Michaud
2021-07-23  7:38             ` Marcel Holtmann
2021-07-23  8:20               ` Szymon Janc [this message]
2021-07-23 13:20                 ` Alain Michaud
2021-07-24  1:24                   ` Miao-chen Chou
2021-06-26  5:52   ` Detailed error code
2021-06-26  5:21 ` [BlueZ PATCH v2 2/3] device: Include BtdError code in Connect() return Miao-chen Chou
2021-06-26  5:21 ` [BlueZ PATCH v2 3/3] client: Print error code for connect methods Miao-chen Chou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2206189.ElGaqSPkdT@ix \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).