Hi Chen, Lizardo, 2011/12/5 Anderson Lizardo <anderson.lizardo@xxxxxxxxxxxxx>: > Hi Chen, > > On Mon, Dec 5, 2011 at 7:10 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote: >> What do you mean restoring the attribute handles ? Each of the profiles registers its own services when the plugin is loaded, according to the load order (which I assume will not change). > > There is no guarantee in the load order. As we add more plugins, you > can't predict the order the plugins will be loaded. > >> When a profile registers its attributes, it can specify callbacks for read/write which are actually function pointers. How to you plan to support this? > > Only attribute *handles* are to be stored (for now). The mapping could > be based on service+characteristic UUIDs (but we need to pay attention > if we have multiple services with same service and characteristic > UUIDs; for this case, I'm not even sure how the client knows which one > to use). > I was thinking in using a sort of server_id to distinguish between services registered among different plugins. That a first idea I have, I'm going to try to send a RFCs patches during these days. As always, I'll be updating my git repository at github if you want to follow my progress. >> In addition, who will be responsible for reloading the database and populating the values (profile plugin or bluetoothd core) ? how do you synchronize them? > > My suggestion would be to implement this in attrib/gatt-service.c so > gatt_service_add() could load attribute handles from storage > transparently. This could also avoid changing every profile. > > Note this is only for *server* roles (e.g. PAS server, TIP server, PXP > reporter etc.). > > I'm not sure what you mean with synchronization. The attribute handles > are to be stored when the service is registered (and you can't change > them after registration). > >> Do you have an RFC or a simple design description which will allow reviewing? > > No. I am not working on this currently. This discussion started from > an idea from Santiago to how to handle registration failures (see > initial post), to which I responded that we may want first to address > attribute handle storage to make sure handles stay the same during > device lifetime (until it is factory reset). > I'll put my hands on this issue. Regards -- 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
