gnokii-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Statemachine: wait for many types


From: Chris Kemp
Subject: Re: Statemachine: wait for many types
Date: Thu, 13 Feb 2003 09:06:55 +0000

On 2003.02.12 20:34 Osma Suominen wrote:
> Hello again,
> 
> this time I have a question concerning the statemachine code
> (common/gsm-statemachine.c). There is a very useful function sm_block
> and several variants of it, which all wait for a message of a certain
> type to come from the phone.
> 
> However, the 3110 protocol is such that the phone usually has different
> return codes (i.e. message types) to indicate a succesful and a failed
> operation. Thus e.g. 0x28 is "SMS sent OK" and 0x29 is "SMS send error".
> 
> The problem is that the driver code doesn't know beforehand if the
> operation will succeed or not, so it has to wait for either of the two
> messages to appear. sm_block(), however, only takes a single expected
> message type as argument. This means that it can't be used for this
> purpose and lower level statemachine functions have to be used instead.
> In practice almost identical copies of the sm_block_timeout() function
> appear in the 3110 driver in many places, and more will come if the 3110
> driver functionality is expanded (e.g. phonebook handling). That is pure
> copy-paste coding and very ugly.
> 
> Now one way of fixing this would be to make a private wrapper function
> in the 3110 code, but I think that's not actually the right place for
> it, because the supposed sm_block_many() function is not in any way
> specific to the 3110 except that other drivers currently don't seem to
> need that kind of functionality.
> 
> To get to the point, I'd like to add a sm_block_many function to
> gsm-statemachine.c, and also perhaps some other variants of it. Now the
> cleanest way of doing this (with the least code duplication) is to
> rewrite the current sm_block_timeout() into a generalized one, say,
> sm_block_many_timeout(), that accepts an array of message types instead
> of one, and make the other functions use that internally (of course,
> with a new sm_block_timeout() that takes just one, for compatibility).
> 
> Is this acceptable to you? If it is, I'll be glad to submit a patch,
> because it makes 3110 maintenance a lot easier for me.

I completely agree that it is sensible to have a sm_block_many_timeout() or
similar, although the block series are just helper functions and it was
intended that in some places the lower level functions would be used
directly.

Shame we can't overload sm_block_timeout to take an array rather than a
single int....

Chris




reply via email to

[Prev in Thread] Current Thread [Next in Thread]