Hi Vinicius, On Thu, May 02, 2013, Vinicius Gomes wrote: > > the long term plan is to use standard types like bool, char, uint8_t > > and also void * here. However we might want to also see how to get > > rid of g_ prefix as well. Especially g_attrib seems to be a good > > candidate to get rid of. > > > > I also like to see ATT and GATT being implemented as src/shared/ > > under LGPL so we can be easily share it in the future. I already > > have some (unpublished) code for src/shared/att.[ch] and > > src/shared/gatt.[ch] already, but I think what we first need to do > > is to figure out how we handle clients and servers from the kernel > > side. Especially with the background of the kernel auto-connecting > > LE channels in the future. > > I am assuming you were talking about the connection establishment. If > not, I am not following. > > I can only think of an evolutionary approach of what we are already > doing: > > - when we are the initiating side, the kernel will only auto-connect > devices that have an associated socket blocking on connect(); the > kernel may even use the white list if it seems appropriate (no > resolvable addresses in the list of "to be connected" sockets for > example). You'll need to sync up with Marcel regarding how this should be done (I'll be effectively offline until next Tuesday so you wont be getting more clarifications from me before that). I've never thought that doing tying connect() to the auto-connect procedure is a good idea, and based on my last chat with Marcel a few days ago he was agreeing. Having a pending connect() for potentially days or even months is not really very intuitive compared to how connect() is typically used. Instead, I think the ATT server socket should always be the point of entry of new connections, regardless of who is initiating. We'll then have a new mgmt command to add devices to a kernel-side list, potentially along with the necessary scan parameters, and the kernel will then do the passive scanning based on that. Johan -- 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
