comparison rvinterf/include/localsock.h @ 0:e7502631a0f9

initial import from freecalypso-sw rev 1033:5ab737ac3ad7
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 11 Jun 2016 00:13:35 +0000
parents
children ca6e969be6ee
comparison
equal deleted inserted replaced
-1:000000000000 0:e7502631a0f9
1 /*
2 * This header defines and describes (through comments) the local UNIX domain
3 * socket interface implemented between rvinterf and its clients like fc-tmsh.
4 *
5 * The UNIX domain sockets used for this ad hoc interface are of the
6 * SOCK_STREAM kind, but the true nature of the communication is message-based.
7 * We use the same trick that is used for DNS over TCP: every message in each
8 * direction is preceded by a 2-byte length. This length is sent MSB first
9 * just like in DNS over TCP. The limit on the size of these messages
10 * (for sizing buffers etc) is:
11 */
12
13 #define LOCALSOCK_MAX_MSG 1024
14
15 /*
16 * Each message in the client->rvinterf direction (can be seen as command)
17 * begins (after the length) with an opcode byte as follows:
18 */
19
20 #define CLI2RVI_WANT_RVTRACE 0x00
21 #define CLI2RVI_WANT_MUXPROTO 0x01
22 #define CLI2RVI_PKT_TO_TARGET 0x02
23 #define CLI2RVI_RAWBYTES_TO_TARGET 0x03
24 #define CLI2RVI_RESET_PACKET_RX 0x04
25 #define CLI2RVI_DROP_MUXPROTO 0x05
26
27 /*
28 * The first two commands (CLI2RVI_WANT_RVTRACE and CLI2RVI_WANT_MUXPROTO)
29 * are the means by which client programs inform rvinterf that they are
30 * interested in receiving copies of certain packets coming from the target.
31 *
32 * The CLI2RVI_WANT_RVTRACE opcode needs to be followed by a USEID mask value
33 * and a USEID match value, both in the network byte order, i.e., MSB first,
34 * for a total message length of 9 bytes. For every RV trace message received
35 * from the target, rvinterf will iterate through all active clients to see who
36 * is interested: if the received USEID ANDed with the mask equals the match
37 * value, the message will be forwarded to that client.
38 *
39 * The CLI2RVI_WANT_MUXPROTO opcode needs to be followed by one byte
40 * identifying the RVTMUX protocol of interest, i.e., the first byte of the
41 * packets exchanged between the host and the target, e.g., 0x12 for L1 traces
42 * as defined in pktmux.h, for a total message length of 2 bytes.
43 *
44 * The CLI2RVI_RESET_PACKET_RX opcode resets the "interests" previously set
45 * with CLI2RVI_WANT_RVTRACE and/or CLI2RVI_WANT_MUXPROTO. It is a "blanket"
46 * reset; the command message consists of just the opcode. The
47 * CLI2RVI_DROP_MUXPROTO command is more specific and undoes the effect of a
48 * previous CLI2RVI_WANT_MUXPROTO; it needs to be followed by one byte
49 * identifying the RVTMUX protocol in question, just like CLI2RVI_WANT_MUXPROTO.
50 *
51 * The last two commands (CLI2RVI_PKT_TO_TARGET and CLI2RVI_RAWBYTES_TO_TARGET)
52 * cause data payload to be sent to the target serial port. Payload following
53 * CLI2RVI_PKT_TO_TARGET (must not exceed MAX_PKT_TO_TARGET) is sent with the
54 * proper packet encapsulation per TI; bytes following
55 * CLI2RVI_RAWBYTES_TO_TARGET are sent raw.
56 */
57
58 /*
59 * Each message in the rvinterf->client direction begins (after the length)
60 * with a message type byte as follows:
61 */
62
63 #define RVI2CLI_PKT_FROM_TARGET 0x00
64 #define RVI2CLI_LOCAL_CMD_RESP 0x01
65
66 /*
67 * Messages beginning with RVI2CLI_PKT_FROM_TARGET are packets received
68 * from the target GSM device; the byte following this type code is the
69 * first byte of the packet from the target, e.g., 0x11 for RV traces or
70 * 0x12 for L1 traces. Rvinterf will only start sending these messages
71 * to a client after that client has expressed interest in receiving
72 * target->host packets of a particular type.
73 *
74 * Messages beginning with RVI2CLI_LOCAL_CMD_RESP are generated locally
75 * by rvinterf itself as responses to commands, currently as responses to
76 * CLI2RVI_WANT_{RVTRACE,MUXPROTO}. The byte following the
77 * RVT2CLI_LOCAL_CMD_RESP type code is ASCII '+' or ASCII '-', indicating
78 * success or error, respectively. Any remaining bytes form a message
79 * for the user.
80 */