Return-Path: MIME-Version: 1.0 In-Reply-To: References: <1322129290-10767-1-git-send-email-sancane@gmail.com> <20111202112957.GC17203@x220.ger.corp.intel.com> Date: Mon, 5 Dec 2011 13:00:14 +0100 Message-ID: Subject: Re: [PATCH 1/2] Provide return status in gatt_service_add function From: Santiago Carot To: Anderson Lizardo Cc: "Ganir, Chen" , "linux-bluetooth@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Chen, Lizardo, 2011/12/5 Anderson Lizardo : > Hi Chen, > > On Mon, Dec 5, 2011 at 7:10 AM, Ganir, Chen 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