Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20211013124210.1454876-1-mmandlik@google.com> <20211013053935.BlueZ.v2.1.I7f6bdb9282c1e12ffc6c662674678f2b1cb69182@changeid>
 <7414EB4C-0422-4BCF-869C-B4FA611DFCFC@holtmann.org>
In-Reply-To: <7414EB4C-0422-4BCF-869C-B4FA611DFCFC@holtmann.org>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Thu, 14 Oct 2021 11:06:12 -0700
Message-ID: <CABBYNZKCVVLR8fHU=kyVtLwRgzUFqTh3rg5p4L5fewcL0=CrWA@mail.gmail.com>
Subject: Re: [BlueZ PATCH v2 1/3] doc: Introduce the Adv Monitor Device Lost event
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     Manish Mandlik <mmandlik@google.com>,
        CrosBT Upstreaming <chromeos-bluetooth-upstreaming@chromium.org>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Marcel, Manish,

On Wed, Oct 13, 2021 at 6:15 AM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Manish,
>
> > Add a flag 'Device Tracked' to the existing 'Device Found' event to
> > indicate that the controller has started tracking the device matching
> > an Advertisement Monitor with handle 'Monitor_Handle'.
> >
> > Add a new event 'Adv Monitor Device Lost' to indicate that the
> > controller has stopped tracking that particular device.
> >
> > ---
> >
> > Changes in v2:
> > - Instead of creating a new 'Device Tracking' event, add a flag 'Device
> >  Tracked' in the existing 'Device Found' event and add a new 'Device
> >  Lost' event to indicate that the controller has stopped tracking that
> >  device.
> >
> > doc/mgmt-api.txt | 32 +++++++++++++++++++++++++++++++-
> > 1 file changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> > index 5355fedb0..0fd884ed0 100644
> > --- a/doc/mgmt-api.txt
> > +++ b/doc/mgmt-api.txt
> > @@ -107,7 +107,8 @@ Configuration command, Default Runtime Configuration Changed event, Get
> > Device Flags command, Set Device Flags command, Device Flags Changed event,
> > Read Advertisement Monitor Features command, Add Advertisement Patterns
> > Monitor command, Remove Advertisement Monitor command, Advertisement Monitor
> > -Added event and Advertisement Monitor Removed event.
> > +Added event, Advertisement Monitor Removed event, Updated Device Found event
> > +and Added Advertisement Monitor Device Lost event.
> >
> >
> > Example
> > @@ -4247,6 +4248,7 @@ Device Found Event
> >                               Address_Type (1 Octet)
> >                               RSSI (1 Octet)
> >                               Flags (4 Octets)
> > +                             Monitor_Handle (2 Octets)
> >                               EIR_Data_Length (2 Octets)
> >                               EIR_Data (0-65535 Octets)
>
> you can not do this. This breaks ABI.

I was going to say that, we can't be adding parameters to existing
commands/events as that is not backward compatible (old bluetoothd
won't be able to parse them properly). That said, I wonder why it
needs the handle though? Wouldn't a flag be enough to indicate that
has been found via monitor filtering or do we need to know the exact
monitor rule that has triggered it?

Btw, afaik monitor handles as 1 octet not 2.

-- 
Luiz Augusto von Dentz