[Top][All Lists]

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

Re: Quirk with on_sms callback

From: Jeremy Lainé
Subject: Re: Quirk with on_sms callback
Date: Wed, 10 Jan 2007 23:20:59 +0100
User-agent: Icedove (X11/20061220)

Hash: SHA1

Hi again!

> +static gn_error AT_GetManufacturer(gn_data *data, struct
> gn_statemachine *state)
> +{
> +    strncpy(data->manufacturer, "Motorola", GN_MANUFACTURER_MAX_LENGTH);
> +    return GN_ERR_NONE;
> +}
> +
> +static gn_error AT_GetModel(gn_data *data, struct gn_statemachine *state)
> +{
> +    strncpy(data->model, "EZX", GN_MODEL_MAX_LENGTH);
> +    return GN_ERR_NONE;
> +}
> The existing way doesn't work?

No, unfortunately not, the baseband processor ("modem") on the EZX
handsets replies neither "OK" nor "ERROR" for the commands it does not
support, it just gives an extended error code. This is why I crippled
the commands querying manufacturer/model, and also why you need to
explicitly set "AT-EZX" as the model, since it is not possible to
determine the driver flavour in the usual fashion.

> +typedef struct {
> +    int length;
> +    char buffer[512];
> +} atezx_mt_sms;
> Why is that?

I use this structure for storing data about incoming SMS notifications.
The problem here is that you get an unsolicited message of the form:

AT+CMT: <some length>

<hex SMS data>

Unfortunately, other unsolicited messages seem to sometimes come between
the two parts (to be confirmed), so I needed to store data somewhere in
the meantime. Come to think of it, I currently don't do anything with
the message length so this could probably be scrapped.

This brings up another topic I would quite like discussing with you
which is the handling of unsolicited messages. There are a number of
messages which I would like to support, but as they are totally specific
to EZX platforms I want to isolate them in the atezx driver. The problem
is that at the moment this is not possible, unsolicited messages are
handled by atbus.c. Is there any way we could delegate this to the
actual phone drivers to allow customisation?

> +    void *extra_data;
> And this one I would really like to avoid.

The atgen driver does not provide any way for derived drivers to store
their additional state data, which is why I added this. There are
basically two approaches here:

a/ we explicitly declare every possible bit of additional information
for all drivers derived from atgen as part of the atgen driver instance
data, and whenever a driver needs a new field we have to go back and
change atgen

b/ we provide an opaque data structure which allows drivers to manage
their own data. This is what I chose.

How would you prefer to see this handled?

Thanks for you comments!


- --             :      : Sailcut CAD : Free Software
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

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