Re: Statemachine: wait for many types

[Osma Suominen]

On Thu, 13 Feb 2003, BORBELY Zoltan wrote:

> The fbus-3110.c code used only by the nk3110.c driver, so we can modify
> it. What about if we call sm_incoming_function with a constant message
> type? It isn't too nice but it's a one line modification. The nk3110.c
> code can decode the original message type from buffer[0].

Hmm...I understand but I don't like the idea. This would mean that the
3110 code would call sm_block with the constant message type (say 0x00)
as argument. What if, say, an incoming call happens right in the middle
of the operation? Would the phone inform about the call with a frame and
thus break the sm_block loop? I don't know if that's possible, but it
sounds like it could cause trouble.

Even though it's a oneline fix in fbus-3110.c it would still require
lots of rewriting in nk3110.c. That has to be done anyway so it's not a
big issue, but still it's not perhaps the easy solution you make it
sound like...

Based on your idea, I also considered changing fbus-3110 so that the
code reported to sm_incoming_function is the message type with the least
significant bit set to 0, because in most cases the LSB is the only
difference between a successful and a failed operation. Unfortunately
not always, responses to DTMF and SMSC setting operations (currently
neither of them implemented) don't follow this rule. They could be
grouped together by zeroing the two least significant bits, but I think
the whole idea would start to resemble another ugly hack and again
create problems of its own.

I'm still in favour of the sm_block_many() function. If you don't want
me to touch the recently modified sm_block() group of functions,
perhaps I can simply add my own function(s) to gsm-statemachine.c, even
if they may (nearly) duplicate some existing code?

-Osma

-- 
*** Osma Suominen *** address@hidden *** http://www.iki.fi/ozone/ ***