Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 19 Jun 2019 08:56:58 +0200
From:   =?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek 
        <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ 0/1] mesh: Move HCI handling to mesh-io-generic
Message-ID: <20190619065658.y5cjqjz764i6wkab@mlowasrzechonek2133>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <20190618112655.19963-1-michal.lowas-rzechonek@silvair.com>
 <34B4A752-E039-4CAD-A8A7-E8CC137DC8A4@intel.com>
 <F5913AD6-9050-422D-8BED-AB6CD2B434D3@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <F5913AD6-9050-422D-8BED-AB6CD2B434D3@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

On 06/18, Gix, Brian wrote:
> > The intent if the architecture was to allow for finer control with
> > future controllers, and thus a mesh-io.c which doesn’t assume
> > anything about underlying controllers, and then an *initial*
> > mesh-io-generic.c which is what gets used by 4.x controllers... as
> > more controllers are supported with finer tuning available, then
> > mesh-io-<bt5+>.c can be added to the abstracted list.
> 
> We are also talking about how to share controllers between bluetoothd
> and meshd...   one idea is using the MGMT interface to send and
> receive specific advertisements...   that would necessitate a
> mesh-io-mgmt.c. However, it will also require support in the kernel.

Yes, I remember that discussion, and fully agree.

I think the proposed patch moves us in this direction, so that mesh-io.c
indeed does not assume *anything* about underlying controllers, up to
the point where mesh-io doesn't need to be aware of interface index -
the mesh-io-api implementation might use whatever transport it wants.

About MGMT calls (MGMT_OP_READ_INDEX_LIST and MGMT_OP_READ_INFO): I
guess the idea was to allow mesh-io-<something> to reuse this part of
the code. If you prefer, I could extract this into mesh-mgmt.c and have
mesh-io-generic call it. This would allow us to implement mesh-io-<bt5+>
in the future, and have it reuse the implementation, using its own
callbacks, while other I/O flavours might skip MGMT calls altogether.

I'd still like to keep mesh.c oblivious to HCI/MGMT/whatever.

Does that sound OK to you?

cheers
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND