Anderson, > -----Original Message----- > From: Anderson Lizardo [mailto:anderson.lizardo@xxxxxxxxxxxxx] > Sent: Monday, December 05, 2011 1:37 PM > To: Ganir, Chen > Cc: Santiago Carot; linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/2] Provide return status in gatt_service_add > function > > 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). > > > 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). > > Regards, > -- > Anderson Lizardo > Instituto Nokia de Tecnologia - INdT > Manaus - Brazil Thanks. Chen Ganir. -- 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
