Hi Tanu, >> Im fine with the changes except with this thing with >> org.bluez.FMRadio, IMO that should belong to the module that requires >> it > > It's a valid argument that "special" stuff like the FMRadio interface > adds clutter in the generic bluetooth-util.h API. But if it's > implemented separately, either it will reimplement a lot of stuff > already done by bluetooth-util, or alternatively bluetooth-util.h will > need to provide an API for extending the functionality, and that would > add another kind of clutter. I believe the extension API would be worse > than having FMRadio directly in bluetooth-util. > > Another argument is that having FMRadio in bluetooth-util causes > overhead in systems where the WL1273 chip isn't used. There is some > additional memory required, which I think is negligible, but there's > also useless D-Bus communication involved, which I think is a > significant drawback. An intermediate position can be that bluetooth-util.c notifies module-wl1273-support that an adapter has been added or removed via hooks similar to what already exists. If this happens, module-wl1273-support could simply look for the org.bluez.FMRadio interface by itself. This way, if module-wl1273-support is not loaded, then no overhead is added, and if it is loaded, it still benefit the shared architecture of bluetooth-util.c. To reduce cluttering, the code for org.bluez.FMRadio could still be hidden in a module specific part, for example : fmradio-util.c built into module-wl1273-support. Regards, Fr?d?ric
