This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi dexter,
thanks for your update!
On Tue, Mar 09, 2010 at 03:12:47PM +0100, dexter wrote:
> I have now getting interrupts and i am sending the first little
> APDUs to the card. I think i will have something that basicly works
> soon.
> But up to now i think it will be impossible to save processing time
> during the transmission - wait phases without having semaphores (or
> something semilar that can be used to wait for an event without
> wasting processing time in a while loop.) However - this only makes
> sense with a multitasking os which we actually do not have ;-)
yes, if you think about a synchronous / "blocking I/O" scenario.
However, you could always have something asynchronous: The caller calls
something like sim_card_transceive(*message, *cb), and the driver calls
back the 'cb' function when it has received the data.
I think the latter is the best we can do at the moment.
Another possible concept is to introduce some kind of message queue: The
entity that wants to issue a command to the SIM sends a message into the
queue, indicating to which other message queue any responses shall be
queued to.
I agree the synchronous approach seems to be the more natural one
(for most human beings at least). However, it comes at the cost of
scheduling overhead/latency, new possibilities for deadlocks and
potentially difficult debugging than in a single-threaded program.
Right now I don't really know yet how many threads/tasks we will end up
having. I only know we should be careful and not to have too many of
them. Layer2 is certainly going to be one task, Layer3 will have at
least one. Layer3 is he entity that normally talks to the SIM, at least
excluding things coming directly from the app like phonebook access and
storing SMS.
> The driver will get a function like sim_card_transceive(*message,
> *response) or so on because a transaction with the card will never
> be receive or send only. You always send something to the card and
> you always get something back.
If the caller does not care, he could simply specify a NULL pointer as
*response.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)