Openmoko gsmd/libgsmd
Go to file
mickey 224af73699 remove changelog, it's incomplete
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@4898 99fdad57-331a-0410-800a-d7fa5415bdb3
2009-01-23 01:00:12 +00:00
doc some further gsmd/libgsmd work 2006-10-22 14:05:53 +00:00
include add missing include of strl.h. patch by khorben. closing OM #2184 2009-01-23 00:59:23 +00:00
logs first compiling (unfinished, not-working) version of userspace gsm infrastructure 2006-09-02 10:32:06 +00:00
src adjust return length for ticket #1591 (Erin Yueh) 2008-09-02 08:26:48 +00:00
COPYING - Add copyright / license notice to all source code files 2007-01-13 09:53:17 +00:00
COPYING.library - Add copyright / license notice to all source code files 2007-01-13 09:53:17 +00:00
ChangeLog remove changelog, it's incomplete 2009-01-23 01:00:12 +00:00
Makefile.am gsm: modernize autotool framework and pkgconfigize it 2006-12-07 15:17:42 +00:00
README.txt some further gsmd/libgsmd work 2006-10-22 14:05:53 +00:00
autogen.sh gsm: modernize autotool framework and pkgconfigize it 2006-12-07 15:17:42 +00:00
configure.ac fix lots of header-related issues with autotools 2007-01-08 12:05:58 +00:00
libgsmd.pc.in gsm: modernize autotool framework and pkgconfigize it 2006-12-07 15:17:42 +00:00

README.txt


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:

- select loop detects data has arrived on user socket
	- gsmd_usock_user_cb()
		- if this is atcmd passthrough, 
			- alloc + fill in gsmd_atcmd
			- atcmd_submit()
				- append it to pending_atcmds
				- mark interest of writing to UART
		- if this is not passthrough
			- do whatever handling, including enqueueing of atcmds
- select loop detects UART is marked writable
	- atcmd_select_cb()
		- iterate over list of pending_atcmds()
			- write a particular atcmd to UART
			- move atcmd to busy_atcmds
- select loop detects UART is marked readable
	- atcmd_select_cb()
		- read up to 1024 bytes into buffer
		- llparse_string()
			- llparse_byte()
				- llparse_append()
			- llp->cb == ml_parse()
				- if this is not unsolicited
					- call cmd->cb() 
						- alloc + fill ucmd reply
						- add to finished_ucmds
						- mark user sock writable
					- unlink + free atcmd
				- if this is unsolicited
					- unsolicited_parse()
						- usock_evt_send()
							- alloc + fill ucmd reply
							- add to finished_ucmds
							- mark user sock writable
- select loop detects user sock writeability
	- gsmd_usock_user_cb()
		- iterate over finished_ucmds
			- write ucmd
			- unlink + free ucmd