All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dara Spieker-Doyle <dara.spieker-doyle@nokia.com>
To: ofono@ofono.org
Subject: Re: [PATCH 2/5] cdma-voicecall: Add CDMA MO Call Support
Date: Tue, 07 Dec 2010 11:09:38 -0800	[thread overview]
Message-ID: <1291748978.3053.23.camel@dardoyle-desktop> (raw)
In-Reply-To: <4CFDA70E.2050103@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3056 bytes --]

Hi Denis

On Tue, 2010-12-07 at 04:16 +0100, ext Denis Kenzior wrote:
> Hi Rajesh,
> 
> On 12/03/2010 03:34 PM, Rajesh.Nagaiah(a)elektrobit.com wrote:
> > 
> > Hi Dara,
> > 
> >> -----Original Message-----
> >> From: ofono-bounces(a)ofono.org 
> >> [mailto:ofono-bounces(a)ofono.org] On Behalf Of Dara Spieker-Doyle
> >> Sent: 03 December 2010 13:21
> >  
> >>>> +enum cdma_call_status {
> >>>> +	CDMA_CALL_STATUS_ACTIVE = 0,
> >>>> +	CDMA_CALL_STATUS_DIALING = 1,
> >>>> +	CDMA_CALL_STATUS_ALERTING = 2,
> >>>> +	CDMA_CALL_STATUS_INCOMING = 4,
> >>>
> >>> Should be 3 ?
> >>
> >> Yes indeed. I will fix this, thank you for catching it.
> >>  
> >>>> +	CDMA_CALL_STATUS_DISCONNECTED
> >>>> +};
> >>>
> >>> We can use the existing gsm call status itself ?
> >>> Just that we wont use the HELD and WAITING status in CDMA.
> >>
> >> In this early phase of CDMA support in oFono, we would like 
> >> to evolve it in its own right for a while, per the offline 
> >> conversation from the MeeGo Conference in Dublin. On a case 
> >> by case basis, for items of large architectural impact, we 
> >> intend to evaluate potential re-use upfront.
> >> The plan is to allow smaller items like this for now, until 
> >> the related feature has matured sufficiently that they can be 
> >> re-factored correctly if applicable.
> >  
> > I agree with the fact that we should evolve it in its own right.
> > But with these kind of straight forward cases, where the GSM values
> > are a superset of the CDMA values and these value definitions being
> > internal to ofono, we should try to to reuse the values rather than
> > creating new ones exclusive for CDMA.
> > Thats my view, Denis/Marcel any comments ?
> > 
> 
> So the general rule of thumb has been to use an int when a spec clearly
> defines the meaning of the said int.  E.g. call status int values have
> very clear meaning from 27.007.  If no such clear definition exists,
> then an enum should be used.

The 3GPP2 does not provide clear definitions, certainly not as thorough
as 27.007
> 
> So the question here becomes whether the CDMA modems all re-use the GSM
> meanings / values for these states or not?  If they do, then re-using
> the GSM enum values makes sense.

As there is no clear 3GPP2 standard for call states, we cannot guarantee
that CDMA modems would all re-use the GSM meanings.
> 
> If not, then using an enum defined in include/cdma-voicecall.h would be
> better.  One major benefit of defining a dedicated enum for CDMA is the
> compiler checking that all enum values are being handled.  If you re-use
> the GSM version you would have to resort to using default statements.
> This causes you to lose that extra compiler sanity checking, not to
> mention is against rule M12 of the coding style.  And yes I know we're
> not always consistent with this one ;)
> 

This is our preference- we can move the cdma enum from /src/common.h
into include/cdma-voicecall.h if you would prefer that location?

Cheers
Dara



  reply	other threads:[~2010-12-07 19:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-02 23:31 [PATCH 2/5] cdma-voicecall: Add CDMA MO Call Support Dara Spieker-Doyle
2010-12-03  0:30 ` Rajesh.Nagaiah
2010-12-03 21:20   ` Dara Spieker-Doyle
2010-12-03 21:34     ` Rajesh.Nagaiah
2010-12-07  3:16       ` Denis Kenzior
2010-12-07 19:09         ` Dara Spieker-Doyle [this message]
2010-12-09  8:05           ` Denis Kenzior
2010-12-09  8:36 ` Denis Kenzior
2010-12-10 21:26   ` Dara Spieker-Doyle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1291748978.3053.23.camel@dardoyle-desktop \
    --to=dara.spieker-doyle@nokia.com \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.