Hi Lucas,
On Tue, Nov 13, 2012 at 8:55 AM, Lucas De Marchi
<lucas.demarchi@xxxxxxxxxxxxxx> wrote:
>> I agree it is not the best solution. Actually, I think we can overcome
>> the problem completely by getting rid of symlinks for "drivers" (like
>> sap-{u8500,dummy}.c, suspend-dummy.c,
>> telephony-{dummy,maemo5,maemo6,ofono}.c) and having everything
>> built-in and enabled/disabled based on which D-Bus services are
>> running on the system (or, if not possible, by using config options).
>
> what do you mean by "running on the system"?
In situations where it is appropriate, we have a
g_dbus_add_service_watch() which will trigger the support code
specific for that service, instead of relying on enabling the service
support at compile time. In practice the support code will be always
compiled.
For situations where the driver code is not related to any D-Bus
service, a config option (in e.g. /etc/bluetooth/<profile>.conf) could
enable/disable the support. The main benefit here is that there will
be no "dead code" that never gets compiled because bootstrap-configure
is not able to enable all drivers.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
