gnokii-users
[Top][All Lists]
Advanced

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

Re: Reviving 3110 support


From: Pawel Kot
Subject: Re: Reviving 3110 support
Date: Tue, 4 Feb 2003 23:38:43 +0100 (CET)

On Tue, 4 Feb 2003, Osma Suominen wrote:

Osma,

> Okay. Based on this piece of information, I'm not trying to
> encode/decode stuff in nk3110.c, but instead wait for changes in eg.
> gsm-sms.c

That's good. I'll try to implement is as more current work is done.

> > Okay, I'm waiting impatiently for the patch.
>
> I put the first public version of the patch here:
> http://sange.fi/~ozone/gnokii/gnokii-0.5.0pre5-nk3110-v0.1.patch.gz

Thanks a lot. The patch looks quite OK right now. If it does compile I'm
going to apply it as it is and give it a try. I hope it will help you in
keeping sync with the main CVS tree.

I understand that the patch is big due to API change, and that's fair. But
for the future I'd like to have one patch per feature.

> The patch is against 0.5.0pre5 and I admit it's pretty ugly. The worst
> hacks can be found by grepping for FIXME. But at least the following
> gnokii commands work:
> --identify
> --sendsms
> --savesms
> --getsms
> --deletesms
> --getsmsc

Okay. I think it's worth to give it a try.

> On my todo list are at least the following things:
> * encode/decode SMS userdata properly
> * remove hardcoded stuff e.g. SMS validity
> * test and debug other functions like data calls
> * do something with the remains of old keepalive code - are they needed
>   at all? If not, they could be removed entirely.

The loop should be itself at the higher level. But keepalive frames are
useful.

> I've met some strange things with the current gnokii code:
>
> * Both SMS centre number and remote number are stored in the gn_sms_raw
>   data struct as BCD strings, with one byte each for number type and
>   length. But why is the length encoded differently for these? At

Because the GSM standard requres this.

>   present there are many places with code like this:
>       data->raw_sms->remote_number[0] =
>               (data->raw_sms->remote_number[0] + 1) / 2 + 1;
>   Why not be consistent? I think this mess could easily be cleaned up.

It can't.

>   Or do the phones or SMS spec require this inconsistency?

Yep, exactly. It is silly, I know. SMSC address is not the part of the PDU
encoded frame -- that is the reason.

> * When saving SMS's, the location in memory can be specified. But the
>   3110 doesn't allow this to be specified AFAIK. However, when it
>   acknowledges a succesful send it tells which location the SMS was
>   saved in. This is put by the driver into the gn_sms_raw struct. But it
>   is not copied (by gsm-sms.c) back into the gn_sms struct, so e.g.
>   command line gnokii reports that the SMS was stored in location 0. Is
>   this a bug? I think other drivers (e.g. nk6100.c) also do the same.

Yes, it is a bug. Would you provide a patch for gsm-sms.c?

> * Many pieces of code use the unsigned char type for strings that are
>   sent to the phone or received from the phone. Doesn't this break on
>   (64-bit) architectures where char's are not 8 bits wide? I noticed
>   that older versions often used u8, which might work better. Is this
>   a problem?

Well, gnokii isn't widely used on 64bit archs, so the problem may not
appear at the moment, but thanks for spotting.

regards
pkot
-- 
mailto:address@hidden :: mailto:address@hidden
http://kt.linuxnews.pl/ :: Kernel Traffic po polsku





reply via email to

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