On Fri, Oct 16, 2020 at 06:48:51PM +0200, Michael Nazzareno Trimarchi wrote:
I would like to know the suggested step to adjust command to support
dual mode of wifi chipset. Do you have time to describe your idea?
I have just a few ideas not really a full battle plan. So it likely if
you start working on them you find them wrong and have a better idea how
to get it working.
Anyway, the main thing is to expose the internal device layer as proper
D-Bus API. That means we should first have a draft of the API (see the
doc directory). As this doesn't change existing API there is no problem.
The tricky part is how to find the D-Bus device objects without breaking
the existing API. One way forward would be to add an GetDevices() method
to the Technology API. Extending the API is not a problem, just changing
existing is a no go.
Obvious the main question is how the existing Technology API and the
Device API interact. In a way we would need a Technology API per device
object. Maybe the object path for the device is also implementing the
Technology API. Any setting on the device object path over rules the
main Technology API settings?
So something like
Also we the net.connman.Manager API needs a GetDevices() etc.
So the main work is to figure out how these interfaces interact and
add the D-Bus code to the device layer. Nothing too complex I hope
though it is not something which can be done in a couple of hours.
Hope this helps!