cdmaphonesim: Add CDMA SMS Support

PATCH Superseded Lei Yu 2 participants 6 messages Dec 22, 2010 Kbuild

Share & tools

Lei Yu

author

2010-12-22 00:02 UTC #0 lore raw

PATCH v2 7/7 cdmaphonesim: Add CDMA SMS Support

---
 Makefile.am               |   10 ++
 plugins/cdmaphonesim.c    |  328 +++++++++++++++++++++++++++++++++++++++++++++
 plugins/cdmaphonesim.conf |   14 ++
 3 files changed, 352 insertions(+), 0 deletions(-)
 create mode 100644 plugins/cdmaphonesim.c
 create mode 100644 plugins/cdmaphonesim.conf

Makefile.am +10 -0

index 771f57d..2e6814e 100644
@@ -247,6 +247,16 @@ builtin_modules += cdma_atmodem
 builtin_sources += drivers/cdmamodem/cdmamodem.h \
 			drivers/cdmamodem/cdmamodem.c \
 			drivers/cdmamodem/sms.c
+
+if PHONESIM
+builtin_modules += cdmaphonesim
+builtin_sources += plugins/cdmaphonesim.c
+
+if DATAFILES
+conf_DATA += plugins/cdmaphonesim.conf
+endif
+endif
+
 endif
 
 builtin_modules += g1

plugins/cdmaphonesim.c new file +328 -0

328 lines not on this page · raw message

plugins/cdmaphonesim.conf new file +14 -0

new file mode 100644
index 0000000..9b8bdac
@@ -0,0 +1,14 @@
+# This is a sample file for the cdmaphonesim configuration
+#
+# It should be installed in your oFono system directory,
+# e.g. /etc/ofono/cdmaphonesim.conf
+#
+# Each group is parsed as a modem device
+#
+# Each group shall@least define the address and port
+#   Address = <valid IPv4 address format>
+#   Port = <valid TCP port>
+
+#[cdmaphonesim]
+#Address=127.0.0.1
+#Port=12345

Signature · 1 line

1.7.0.4

Marcel Holtmann

2010-12-22 13:41 UTC #1 lore raw

Hi Lei,

Quoted 6 lines

 Makefile.am               |   10 ++
 plugins/cdmaphonesim.c    |  328 +++++++++++++++++++++++++++++++++++++++++++++
 plugins/cdmaphonesim.conf |   14 ++
 3 files changed, 352 insertions(+), 0 deletions(-)
 create mode 100644 plugins/cdmaphonesim.c
 create mode 100644 plugins/cdmaphonesim.conf

do we really want to do it this way? I am not so sure that this is the best way.

I would prefer to just have one /etc/ofono/phonesim.conf configuration file. And maybe we need to start splitting phonesim plugin into a view pieces and move it to its own directory. It then could also contain its own atom driver implementations there.

So my main concern here is really that phonesim support is just for engineering. It has nothing to do with real production hardware. And I don't wanna clutter the source or its installation with it.

Regards

Marcel

Lei Yu

author

2010-12-22 16:14 UTC #2 lore raw

Hi Marcel,

Quoted 12 lines · ext Marcel Holtmann

Hi Lei,
Quoted 6 lines
  Makefile.am               |   10 ++
  plugins/cdmaphonesim.c    |  328 +++++++++++++++++++++++++++++++++++++++++++++
  plugins/cdmaphonesim.conf |   14 ++
  3 files changed, 352 insertions(+), 0 deletions(-)
create mode 100644 plugins/cdmaphonesim.c
create mode 100644 plugins/cdmaphonesim.conf
do we really want to do it this way? I am not so sure that this is the best way.

Quoted 8 lines

I would prefer to just have one /etc/ofono/phonesim.conf configuration file. And maybe we need to start splitting phonesim plugin into a view pieces and move it to its own directory. It then could also contain its own atom driver implementations there.
So my main concern here is really that phonesim support is just for engineering. It has nothing to do with real production hardware. And I don't wanna clutter the source or its installation with it.

I do see your points. I agree having one phonesim.conf instead of creating a separate installation/configuration file for cdmaphonesim. In terms of whether having seperate cdmaphonesim plugin from phonesim, Denis and myself has discussed in the mailing list, please see:

    http://lists.ofono.org/pipermail/ofono/2010-December/006629.html

To re-cap some of the points and what we have agreed in previous discussion:
The benefit of having separate cdmaphonesim plugin is to not clutter
existing GSM based phonesim plugin with a lot of if/else to cover CDMA and let CDMA evolve on its own path for a while, at least having most of the atoms supported, we can then evaluate how much commonality we have and whether it makes sense to merge cdmaphonesim.c with phonesim.c.
Another benefit or point we have considered is to cause as little
disruption to GSM side as possible.

Thus, I would propose followings:
a). Remove cdmaphonesim.conf and add one additional entry within
phonesim.conf to support cdmaphonesim plugin.
b). Keep cdmaphonesim.c and phonesim.c separated and let CDMA
evolving on its own for now.

Looking forward to hearing you, Denis and other people's oppinions on this topic.

Quoted 10 lines

Regards
Marcel
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono

Regards,
Lei

Marcel Holtmann

2010-12-22 16:09 UTC #3 lore raw

Hi Lei,

Quoted 33 lines

Quoted 10 lines
Quoted 6 lines
  Makefile.am               |   10 ++
  plugins/cdmaphonesim.c    |  328 +++++++++++++++++++++++++++++++++++++++++++++
  plugins/cdmaphonesim.conf |   14 ++
  3 files changed, 352 insertions(+), 0 deletions(-)
create mode 100644 plugins/cdmaphonesim.c
create mode 100644 plugins/cdmaphonesim.conf
do we really want to do it this way? I am not so sure that this is the best way.
Quoted 8 lines
I would prefer to just have one /etc/ofono/phonesim.conf configuration file. And maybe we need to start splitting phonesim plugin into a view pieces and move it to its own directory. It then could also contain its own atom driver implementations there.
So my main concern here is really that phonesim support is just for engineering. It has nothing to do with real production hardware. And I don't wanna clutter the source or its installation with it.
I do see your points. I agree having one phonesim.conf instead of creating a separate installation/configuration file for cdmaphonesim. In terms of whether having seperate cdmaphonesim plugin from phonesim, Denis and myself has discussed in the mailing list, please see:
    http://lists.ofono.org/pipermail/ofono/2010-December/006629.html
To re-cap some of the points and what we have agreed in previous discussion:
The benefit of having separate cdmaphonesim plugin is to not clutter
existing GSM based phonesim plugin with a lot of if/else to cover CDMA and let CDMA evolve on its own path for a while, at least having most of the atoms supported, we can then evaluate how much commonality we have and whether it makes sense to merge cdmaphonesim.c with phonesim.c.
Another benefit or point we have considered is to cause as little
disruption to GSM side as possible.

Quoted 5 lines

Thus, I would propose followings:
a). Remove cdmaphonesim.conf and add one additional entry within
phonesim.conf to support cdmaphonesim plugin.
b). Keep cdmaphonesim.c and phonesim.c separated and let CDMA
evolving on its own for now.

sounds good enough for me now. Have one /etc/ofono/phonesim.conf and each plugin picks the entries it cares about. And for now we keep two plugins, but at some point we have to revisit this.

Regards

Marcel

Lei Yu

author

2010-12-22 16:23 UTC #4 lore raw

Hi Marcel,

Quoted 41 lines · ext Marcel Holtmann

Hi Lei,
Quoted 33 lines
Quoted 10 lines
Quoted 6 lines
   Makefile.am               |   10 ++
   plugins/cdmaphonesim.c    |  328 +++++++++++++++++++++++++++++++++++++++++++++
   plugins/cdmaphonesim.conf |   14 ++
   3 files changed, 352 insertions(+), 0 deletions(-)
create mode 100644 plugins/cdmaphonesim.c
create mode 100644 plugins/cdmaphonesim.conf
do we really want to do it this way? I am not so sure that this is the best way.
Quoted 8 lines
I would prefer to just have one /etc/ofono/phonesim.conf configuration file. And maybe we need to start splitting phonesim plugin into a view pieces and move it to its own directory. It then could also contain its own atom driver implementations there.
So my main concern here is really that phonesim support is just for engineering. It has nothing to do with real production hardware. And I don't wanna clutter the source or its installation with it.
I do see your points. I agree having one phonesim.conf instead of creating a separate installation/configuration file for cdmaphonesim. In terms of whether having seperate cdmaphonesim plugin from phonesim, Denis and myself has discussed in the mailing list, please see:
     http://lists.ofono.org/pipermail/ofono/2010-December/006629.html
To re-cap some of the points and what we have agreed in previous discussion:
The benefit of having separate cdmaphonesim plugin is to not clutter
existing GSM based phonesim plugin with a lot of if/else to cover CDMA and let CDMA evolve on its own path for a while, at least having most of the atoms supported, we can then evaluate how much commonality we have and whether it makes sense to merge cdmaphonesim.c with phonesim.c.
Another benefit or point we have considered is to cause as little
disruption to GSM side as possible.
Quoted 5 lines
Thus, I would propose followings:
a). Remove cdmaphonesim.conf and add one additional entry within
phonesim.conf to support cdmaphonesim plugin.
b). Keep cdmaphonesim.c and phonesim.c separated and let CDMA
evolving on its own for now.

Quoted 3 lines

sounds good enough for me now. Have one /etc/ofono/phonesim.conf and each plugin picks the entries it cares about. And for now we keep two plugins, but at some point we have to revisit this.

Yes, we will need to revisit this and other part of the CDMA for similarities with GSM down the road. Will get going on v3 of the patch. :-)

Quoted 6 lines

Regards
Marcel

Regards
Lei

Lei Yu

author

2010-12-22 21:07 UTC #5 lore raw

Hi, Marcel and all,

Quoted 60 lines · ext Lei Yu

Hi Marcel,
Quoted 43 lines · ext Marcel Holtmann
Hi Lei,
Quoted 35 lines
Quoted 11 lines
Quoted 7 lines
Makefile.am | 10 ++
plugins/cdmaphonesim.c | 328
+++++++++++++++++++++++++++++++++++++++++++++
plugins/cdmaphonesim.conf | 14 ++
3 files changed, 352 insertions(+), 0 deletions(-)
create mode 100644 plugins/cdmaphonesim.c create mode 100644 plugins/cdmaphonesim.conf
do we really want to do it this way? I am not so sure that this is the best way.
Quoted 8 lines
I would prefer to just have one /etc/ofono/phonesim.conf configuration file. And maybe we need to start splitting phonesim plugin into a view pieces and move it to its own directory. It then could also contain its own atom driver implementations there.
So my main concern here is really that phonesim support is just for engineering. It has nothing to do with real production hardware. And I don't wanna clutter the source or its installation with it.
I do see your points. I agree having one phonesim.conf instead of creating a separate installation/configuration file for cdmaphonesim. In terms of whether having seperate cdmaphonesim plugin from phonesim, Denis and myself has discussed in the mailing list, please see:
http://lists.ofono.org/pipermail/ofono/2010-December/006629.html
To re-cap some of the points and what we have agreed in previous discussion:
The benefit of having separate cdmaphonesim plugin is to not clutter existing GSM based phonesim plugin with a lot of if/else to cover CDMA and let CDMA evolve on its own path for a while, at least having most of the atoms supported, we can then evaluate how much commonality we have and whether it makes sense to merge cdmaphonesim.c with phonesim.c. Another benefit or point we have considered is to cause as little disruption to GSM side as possible.
Quoted 5 lines
Thus, I would propose followings:
a). Remove cdmaphonesim.conf and add one additional entry within phonesim.conf to support cdmaphonesim plugin.
b). Keep cdmaphonesim.c and phonesim.c separated and let CDMA evolving on its own for now.
Quoted 3 lines
sounds good enough for me now. Have one /etc/ofono/phonesim.conf and each plugin picks the entries it cares about. And for now we keep two plugins, but at some point we have to revisit this.
Yes, we will need to revisit this and other part of the CDMA for similarities with GSM down the road. Will get going on v3 of the patch. :-)
Quoted 6 lines
Regards
Marcel

Quoted 6 lines

Regards
Lei
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono

I just submitted v3 of this patch fixing the issue Marcel brought up. Pls review v3 instead of v2.

Regards
Lei