[Top][All Lists]
[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