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
next prev parent 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).