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/.
Sébastien Lorquet squalyl at gmail.comWe cross posted, you gave me more info, thanks. The async approach seems very nice here. Sebastien On Tue, Mar 9, 2010 at 4:24 PM, Harald Welte <laforge at gnumonks.org> wrote: > Hi 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) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100309/70af4d32/attachment.htm>