Hi, On Wed, Mar 3, 2010 at 5:32 AM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > Hi Luiz, > > On Tue, Mar 02, 2010, Luiz Augusto von Dentz wrote: >> Data notiated in a session should be reset once disconnected, to fix >> this a new structure is introduced called headset_session is >> introduced to hold the session data which is freed when disconnected. > > In general the idea of the patch is good, but there are a few things > that need some further thinking. > > First of all could we just call a "session" what the HFP spec calls it, > i.e. a Service Level Connection, e.g. hs->slc? Or do you have some > better suggestion? I suggested session since it represents the connection itself, even the at comands buffer is in the new structure so I guess it doesn't really represents slc, maybe connection is more suitable since there could be only one. > Secondly you need to be careful when doing one-to-one replacements of > existing hs->foo statements with hs->session->foo statements. What if > hs->session is NULL? Are there some valid use cases when a function that > can access hs->session could get called while hs->session is NULL? Afaik no there aren't, the session represent the lifetime of the rfcomm connection and the only thing that are accessible are the gains via dbus interface but we protect them by checking the state and if by some reason we don't have a session then there is probably a bug so checking hs->session would probably hide those. -- Luiz Augusto von Dentz Computer Engineer -- 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
