linux-bluetooth.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).