linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alain Michaud <alainmichaud@google.com>
To: Szymon Janc <szymon.janc@codecoup.pl>
Cc: Marcel Holtmann <marcel@holtmann.org>,
	Miao-chen Chou <mcchou@chromium.org>,
	Bluetooth Kernel Mailing List  <linux-bluetooth@vger.kernel.org>,
	Luiz Augusto von Dentz <luiz.von.dentz@intel.com>,
	Alain Michaud <alainm@chromium.org>,
	Howard Chung <howardchung@google.com>
Subject: Re: [BlueZ PATCH v2 1/3] error: BR/EDR and LE connection failure reasons
Date: Fri, 23 Jul 2021 09:20:17 -0400	[thread overview]
Message-ID: <CALWDO_UPexnNmFSf8i8ONkEfQknLqacgw8k4MQs9pejWnD99jQ@mail.gmail.com> (raw)
In-Reply-To: <2206189.ElGaqSPkdT@ix>

On Fri, Jul 23, 2021 at 4:20 AM Szymon Janc <szymon.janc@codecoup.pl> wrote:
>
> Hi,
>
> 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?
>
>
> [1] https://marc.info/?l=linux-bluetooth&m=145710680912268&w=2
> [2] https://marc.info/?l=linux-bluetooth&m=145973293118003&w=2
Definitely worth reconsidering.  We've recently introduced a ConnectLE
Api as a stop gap measure for something very similar.  I'd love to see
the equivalent of a ConnectClassic / ConnectLE distinction.

However, I still believe the "Generic" Connect serves its purpose as
you alluded to above.  Even if it could be built using layers, I still
believe there is value from a telemetry POV to understand the errors
from the field better and there, the distinction between the specific
transport matter.  Just like today, I suspect many applications will
continue to use the generic "Connect" as to not replicate the logic it
ultimately implements for dealing with dual mode devices, yet
results/metrics would be important.

The team strives to improve interoperability at a large scale in the
ecosystem, I believe these data point distinctions are a critical
enabler to get better insights into the specific errors customers are
seeing.  A counter proposal that would be acceptable to you, achieves
the objectives and that the team can implement would be a nice next
step.

Thanks!
Alain
>
>
> --
> pozdrawiam
> Szymon Janc
>
>

  reply	other threads:[~2021-07-23 13:21 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
2021-07-23 13:20                 ` Alain Michaud [this message]
2021-07-24  1:24                   ` Miao-chen Chou
2021-06-26  5:52   ` Detailed error code bluez.test.bot
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=CALWDO_UPexnNmFSf8i8ONkEfQknLqacgw8k4MQs9pejWnD99jQ@mail.gmail.com \
    --to=alainmichaud@google.com \
    --cc=alainm@chromium.org \
    --cc=howardchung@google.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.von.dentz@intel.com \
    --cc=marcel@holtmann.org \
    --cc=mcchou@chromium.org \
    --cc=szymon.janc@codecoup.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).