[RFC] bluetooth: Add support for org.bluez.Adapter and org.bluez.FMRadio.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux