Hi Ajay, On Thu, Jun 16, 2011 at 3:15 AM, Ajay Pillai <Ajay.Pillai@xxxxxxx> wrote: > I have been reading some posts where the GATT profiles were referred to as "plugins". > > Could you tell me what is a "plugin" in this context? It is a BlueZ plugin. See the plugins/ directory on BlueZ sources for example of simple (non-GATT) plugins. There are other plugins dedicated directories as well, run "grep -R BLUETOOTH_PLUGIN_DEFINE *" on source to find them. > Are these profiles running in a separate process space (to rest of BlueZ having GATT /ATT)? Same process. They are usually builtin (statically linked with bluetoothd binary), but can be also .so files loaded when bluetoothd is started. > Can these profiles be brought up and down at run time? Not really. But they can be prevented from being started, if you pass the -P <pluginname> option. > Can nonstandard usecases be implemented and plugged in to use GATT from BlueZ? If you implement your own BlueZ plugin, yes. But be sure to check the BlueZ license, I don't know if standalone plugins would have to follow the same license as BlueZ itself (I assume yes, as there is no "exception" to GPL like on kernel). > I am happy to have some code references that can show me the answer to these. Be sure to follow the latest LE related patches which are being sent to the list, and the ones which are going to be sent in the next days. We are trying to submit upstream the infrastructure necessary for implementing LE profiles ASAP. They will be probably sent as RFC, as they add new infrastructure which we would like to get some feedback first. 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
