All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Waldemar.Rymarkiewicz@tieto.com
Cc: suraj@Atheros.com, Suraj.Sumangala@Atheros.com,
	linux-bluetooth@vger.kernel.org, Jothikumar.Mothilal@Atheros.com
Subject: RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
Date: Fri, 17 Sep 2010 08:04:30 +0900	[thread overview]
Message-ID: <1284678270.2405.148.camel@localhost.localdomain> (raw)
In-Reply-To: <99B09243E1A5DA4898CDD8B700111448097968EDE3@EXMB04.eu.tieto.com>

Hi Waldemar,

> >if we talk about the SAP server role found in a mobile phone, 
> >then that support clearly needs to interact with the telephony 
> >stack. Since when SAP is active the telephony stack needs to 
> >be suspended and all SIM transaction being forwarded.
> 
> I agree, but a telephony stack needs to care about its state when SAP is active. Not all linux based mobile platforms use ofono.

I think they should use oFono of course since that is the only way to be
modem hardware agnostic in the long run.

> >Currently I would be thinking that the SAP implementation 
> >should be done inside oFono actually. Since then you have 
> >direct access to the hardware. The D-Bus approach just doesn't 
> >sound correct to me. I could be of course wrong, but I can't 
> >wrap my mind around on how you can make this work.
> 
> I assume that ofono should handle sap transactions (as it's kind of hardware abstraction for bluez) and expose SAP APDU interfaces as i.e Nokia did for sap transactions in spec (http://www.wirelessmodemapi.com/), and not implement sap profile itself.  Again, not all use ofono as telephony stack.
> 
> Sorry, I don't know ofono well. What's the interface between ofono and bluez? 

In this case there will be no direct interface besides oFono registering
the SDP records for SAP.

> >Even with file descriptor passing this doesn't look like the 
> >right approach. If we need a hardware abstraction than we 
> >either use oFono or we have to create some SAP hardware access 
> >abstraction.
> 
> I agree with this too. I prefere to have a sap implementation as bluez plugin, but we need to define api for sim operations which could be implemented in ofono or other proprietary stacks. I guess dbus was intended to be kind of hw abstraction api.
> Some time ago Claudio sent proposal implementation of sap server where he defined api for a driver to sim.

I still don't see this as a really good idea. We want modem abstraction
inside oFono and not all over the place.

Regards

Marcel



      parent reply	other threads:[~2010-09-16 23:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-13 10:43 [RFC] BlueZ D-Bus Sim Access Profile Server API description Suraj Sumangala
2010-09-13 10:59 ` Johan Hedberg
2010-09-13 11:31   ` Suraj Sumangala
2010-09-13 13:20     ` Johan Hedberg
2010-09-13 15:18       ` Suraj Sumangala
2010-09-13 16:47         ` Johan Hedberg
2010-09-14  5:00           ` Suraj Sumangala
2010-09-13 12:11 ` Waldemar.Rymarkiewicz
2010-09-13 12:29   ` Suraj Sumangala
2010-09-13 12:47     ` Waldemar.Rymarkiewicz
2010-09-13 15:25       ` Suraj Sumangala
2010-09-14  5:42 ` Marcel Holtmann
2010-09-14  6:28   ` Suraj Sumangala
2010-09-15  3:44     ` Marcel Holtmann
2010-09-15  6:14       ` Suraj Sumangala
2010-09-15  7:32         ` Nicolas GUILBAUD
2010-09-15  8:24           ` Suraj Sumangala
2010-09-15  8:56             ` Nicolas GUILBAUD
2010-09-16 23:00           ` Marcel Holtmann
2010-09-17 11:01             ` Nicolas GUILBAUD
2010-09-18  0:16               ` Marcel Holtmann
2010-09-15  9:18       ` Waldemar.Rymarkiewicz
2010-09-16  7:50         ` Suraj Sumangala
2010-09-16 23:04         ` Marcel Holtmann [this message]

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=1284678270.2405.148.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --cc=Jothikumar.Mothilal@Atheros.com \
    --cc=Suraj.Sumangala@Atheros.com \
    --cc=Waldemar.Rymarkiewicz@tieto.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=suraj@Atheros.com \
    /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.