Re: [PATCH] Fix using invalid data from previous headset connection

[Luiz Augusto von Dentz <luiz.dentz@gmail.com>]

Hi,

On Wed, Mar 3, 2010 at 5:32 AM, Johan Hedberg <johan.hedberg@gmail.com> 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