Re: Quirk with on_sms callback

[Pawel Kot]

Hi,

On 1/10/07, Jeremy Lainé <address@hidden> wrote:
> > +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.

If I understand correctly it returns some error code for AT+CGMM or AT+CGMI?

I'd also change the way of doing initialization in some nicer way but
I will come up with some idea soon.

> > +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?

I need to give it more thinking so I will answer that part later.
Specifically I think we may have it adressed in the other drivers.

BTW. if you'd like to chat online you are welcome to #gnokii at freenode.

> > +    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?

What I don't like is void*. I'd prefer structure explicitely defined
by each subdriver upaqued by the union in the atgen driver. So that is
something between a and b.
And that would be handled in the similiar way to
nk6100_driver_instance from nk6100 driver.

take care,
pkot
PS. It's really good to see someone new doing real development! :)
--
Pawel Kot