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@xxxxxxxxxxx> Silvair http://silvair.com Jasnogórska 44, 31-358 Krakow, POLAND
