From bf9b037645a5943e3ba0220be55f7f875445bd5a Mon Sep 17 00:00:00 2001 From: laforge Date: Sun, 22 Oct 2006 14:05:53 +0000 Subject: some further gsmd/libgsmd work git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@96 99fdad57-331a-0410-800a-d7fa5415bdb3 --- README.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'README.txt') diff --git a/README.txt b/README.txt index 5ea8894..22988fe 100644 --- a/README.txt +++ b/README.txt @@ -2,13 +2,35 @@ 1. GSMD api towards libgsmd - provides api for other processes to interact with GSM subsystem + - is not documented and subject to change 2. GSMD api towards vendor-specific plugins - implement vendor-specific AT commands + - is not documented and will initially only support TI + - later, a Motorola plugin is planned. 3. libgsmd api towards applications - wraps GSMD-libgsmd api into C functions that can be used by applications + - will be documented and is supposed to be stable. +3.1. Events + +The application registers callback handlers for events. libgsmd can call these callback +handlers at any given time. Events include "incoming call", "remote end hangup", ... + +3.2. Commands + +Commands have the form of command-reply. Usually they will be performed +synchronously, i.e. the the caller will be blocked until a response to the command has been +received. + +If this behaviour is not desired, a completion handler callback function can be +registered. In this case, the function call will return immediately after the +command has been sent to gsmd. Further incoming packets on the gsmd socket +will be handled to libgsmd by calling lgsm_handle_packet(). If one such packet is the +response to a currently-executing command, the completion handler will be +called from within lgsm_handle_packet(). Matching of responses to requests is done by +assigning a unique id to each request. gsmd responses will have a matching id. code flow in gsmd: -- cgit v1.2.3