linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Suraj Sumangala <suraj@Atheros.com>
Cc: Suraj Sumangala <Suraj.Sumangala@Atheros.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	Jothikumar Mothilal <Jothikumar.Mothilal@Atheros.com>
Subject: Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
Date: Wed, 15 Sep 2010 12:44:24 +0900	[thread overview]
Message-ID: <1284522264.2405.89.camel@localhost.localdomain> (raw)
In-Reply-To: <4C8F160B.4010401@Atheros.com>

Hi Suraj,

> >> Below is the Sim Access Profile server role API discription.
> >> Please let me know your comments.
> >
> > my obvious question is why do we wanna do this over D-Bus and not
> > connect it directly to the hardware via a plugin?
> 
> You meant creating something like a tty device and let the hardware 
> connect directly to this?
> 
> The initial plan was to use a D-Bus file descriptor and transfer the SAP 
> packets to the agent over it.
> 
> The problem was the SAP packet format is specified by the Bluetooth SAP 
> spec. I could not relate it to any generic packet format ( Like HF, HS, 
> DUN can be mapped to an AT parser).
> 
> I am not sure if any existing card reader implementation could parse it 
> to extract SIM card related data (APDU) without additional support for it.
> 
> Another reason I thought about D-Bus was because, most of the SAP 
> operations are Request/Response type like Reset, SimOn etc.
> 
> It mapped better with a Method/Signal communication than packet transfer.
> 
> Some of the card reader implementation I checked had proprietary packet 
> format. So not sure how we could interface with them.
> >
> > Remember that SIM transaction are timing critical and just relaying them
> > over D-Bus doesn't sound the right approach right now. While of course
> > even bluetoothd can't guarantee and response time, it is clearly better
> > than over D-Bus.
> >
> 
> I would really appreciate if you can give me any idea about working 
> around the above mentioned issues.

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.

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.

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.

The SAP client role found a carkit is obviously a different story.

Regards

Marcel



  reply	other threads:[~2010-09-15  3:44 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 [this message]
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

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=1284522264.2405.89.camel@localhost.localdomain \
    --to=marcel@holtmann.org \
    --cc=Jothikumar.Mothilal@Atheros.com \
    --cc=Suraj.Sumangala@Atheros.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).