diff options
author | David S. Miller <davem@davemloft.net> | 2009-10-07 01:43:16 -0400 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2009-10-07 01:43:16 -0400 |
commit | 7ecc59c1b7fd5749667fc31f8683099cbef38977 (patch) | |
tree | 560d8ce48fac50758d1af6d722bc0bb0c7de2a34 /Documentation | |
parent | bcdce7195e0eab55b37dbd53be53057f38006380 (diff) | |
parent | 1cec9727fbfd7baff2034796154be1a0297bcedd (diff) |
Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/isdn/INTERFACE.CAPI | 83 | ||||
-rw-r--r-- | Documentation/networking/pktgen.txt | 8 |
2 files changed, 75 insertions, 16 deletions
diff --git a/Documentation/isdn/INTERFACE.CAPI b/Documentation/isdn/INTERFACE.CAPI index 686e107923ec..5fe8de5cc727 100644 --- a/Documentation/isdn/INTERFACE.CAPI +++ b/Documentation/isdn/INTERFACE.CAPI | |||
@@ -60,10 +60,9 @@ open() operation on regular files or character devices. | |||
60 | 60 | ||
61 | After a successful return from register_appl(), CAPI messages from the | 61 | After a successful return from register_appl(), CAPI messages from the |
62 | application may be passed to the driver for the device via calls to the | 62 | application may be passed to the driver for the device via calls to the |
63 | send_message() callback function. The CAPI message to send is stored in the | 63 | send_message() callback function. Conversely, the driver may call Kernel |
64 | data portion of an skb. Conversely, the driver may call Kernel CAPI's | 64 | CAPI's capi_ctr_handle_message() function to pass a received CAPI message to |
65 | capi_ctr_handle_message() function to pass a received CAPI message to Kernel | 65 | Kernel CAPI for forwarding to an application, specifying its ApplID. |
66 | CAPI for forwarding to an application, specifying its ApplID. | ||
67 | 66 | ||
68 | Deregistration requests (CAPI operation CAPI_RELEASE) from applications are | 67 | Deregistration requests (CAPI operation CAPI_RELEASE) from applications are |
69 | forwarded as calls to the release_appl() callback function, passing the same | 68 | forwarded as calls to the release_appl() callback function, passing the same |
@@ -142,6 +141,7 @@ u16 (*send_message)(struct capi_ctr *ctrlr, struct sk_buff *skb) | |||
142 | to accepting or queueing the message. Errors occurring during the | 141 | to accepting or queueing the message. Errors occurring during the |
143 | actual processing of the message should be signaled with an | 142 | actual processing of the message should be signaled with an |
144 | appropriate reply message. | 143 | appropriate reply message. |
144 | May be called in process or interrupt context. | ||
145 | Calls to this function are not serialized by Kernel CAPI, ie. it must | 145 | Calls to this function are not serialized by Kernel CAPI, ie. it must |
146 | be prepared to be re-entered. | 146 | be prepared to be re-entered. |
147 | 147 | ||
@@ -154,7 +154,8 @@ read_proc_t *ctr_read_proc | |||
154 | system entry, /proc/capi/controllers/<n>; will be called with a | 154 | system entry, /proc/capi/controllers/<n>; will be called with a |
155 | pointer to the device's capi_ctr structure as the last (data) argument | 155 | pointer to the device's capi_ctr structure as the last (data) argument |
156 | 156 | ||
157 | Note: Callback functions are never called in interrupt context. | 157 | Note: Callback functions except send_message() are never called in interrupt |
158 | context. | ||
158 | 159 | ||
159 | - to be filled in before calling capi_ctr_ready(): | 160 | - to be filled in before calling capi_ctr_ready(): |
160 | 161 | ||
@@ -171,14 +172,40 @@ u8 serial[CAPI_SERIAL_LEN] | |||
171 | value to return for CAPI_GET_SERIAL | 172 | value to return for CAPI_GET_SERIAL |
172 | 173 | ||
173 | 174 | ||
174 | 4.3 The _cmsg Structure | 175 | 4.3 SKBs |
176 | |||
177 | CAPI messages are passed between Kernel CAPI and the driver via send_message() | ||
178 | and capi_ctr_handle_message(), stored in the data portion of a socket buffer | ||
179 | (skb). Each skb contains a single CAPI message coded according to the CAPI 2.0 | ||
180 | standard. | ||
181 | |||
182 | For the data transfer messages, DATA_B3_REQ and DATA_B3_IND, the actual | ||
183 | payload data immediately follows the CAPI message itself within the same skb. | ||
184 | The Data and Data64 parameters are not used for processing. The Data64 | ||
185 | parameter may be omitted by setting the length field of the CAPI message to 22 | ||
186 | instead of 30. | ||
187 | |||
188 | |||
189 | 4.4 The _cmsg Structure | ||
175 | 190 | ||
176 | (declared in <linux/isdn/capiutil.h>) | 191 | (declared in <linux/isdn/capiutil.h>) |
177 | 192 | ||
178 | The _cmsg structure stores the contents of a CAPI 2.0 message in an easily | 193 | The _cmsg structure stores the contents of a CAPI 2.0 message in an easily |
179 | accessible form. It contains members for all possible CAPI 2.0 parameters, of | 194 | accessible form. It contains members for all possible CAPI 2.0 parameters, |
180 | which only those appearing in the message type currently being processed are | 195 | including subparameters of the Additional Info and B Protocol structured |
181 | actually used. Unused members should be set to zero. | 196 | parameters, with the following exceptions: |
197 | |||
198 | * second Calling party number (CONNECT_IND) | ||
199 | |||
200 | * Data64 (DATA_B3_REQ and DATA_B3_IND) | ||
201 | |||
202 | * Sending complete (subparameter of Additional Info, CONNECT_REQ and INFO_REQ) | ||
203 | |||
204 | * Global Configuration (subparameter of B Protocol, CONNECT_REQ, CONNECT_RESP | ||
205 | and SELECT_B_PROTOCOL_REQ) | ||
206 | |||
207 | Only those parameters appearing in the message type currently being processed | ||
208 | are actually used. Unused members should be set to zero. | ||
182 | 209 | ||
183 | Members are named after the CAPI 2.0 standard names of the parameters they | 210 | Members are named after the CAPI 2.0 standard names of the parameters they |
184 | represent. See <linux/isdn/capiutil.h> for the exact spelling. Member data | 211 | represent. See <linux/isdn/capiutil.h> for the exact spelling. Member data |
@@ -190,18 +217,19 @@ u16 for CAPI parameters of type 'word' | |||
190 | 217 | ||
191 | u32 for CAPI parameters of type 'dword' | 218 | u32 for CAPI parameters of type 'dword' |
192 | 219 | ||
193 | _cstruct for CAPI parameters of type 'struct' not containing any | 220 | _cstruct for CAPI parameters of type 'struct' |
194 | variably-sized (struct) subparameters (eg. 'Called Party Number') | ||
195 | The member is a pointer to a buffer containing the parameter in | 221 | The member is a pointer to a buffer containing the parameter in |
196 | CAPI encoding (length + content). It may also be NULL, which will | 222 | CAPI encoding (length + content). It may also be NULL, which will |
197 | be taken to represent an empty (zero length) parameter. | 223 | be taken to represent an empty (zero length) parameter. |
224 | Subparameters are stored in encoded form within the content part. | ||
198 | 225 | ||
199 | _cmstruct for CAPI parameters of type 'struct' containing 'struct' | 226 | _cmstruct alternative representation for CAPI parameters of type 'struct' |
200 | subparameters ('Additional Info' and 'B Protocol') | 227 | (used only for the 'Additional Info' and 'B Protocol' parameters) |
201 | The representation is a single byte containing one of the values: | 228 | The representation is a single byte containing one of the values: |
202 | CAPI_DEFAULT: the parameter is empty | 229 | CAPI_DEFAULT: The parameter is empty/absent. |
203 | CAPI_COMPOSE: the values of the subparameters are stored | 230 | CAPI_COMPOSE: The parameter is present. |
204 | individually in the corresponding _cmsg structure members | 231 | Subparameter values are stored individually in the corresponding |
232 | _cmsg structure members. | ||
205 | 233 | ||
206 | Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert | 234 | Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert |
207 | messages between their transport encoding described in the CAPI 2.0 standard | 235 | messages between their transport encoding described in the CAPI 2.0 standard |
@@ -297,3 +325,26 @@ char *capi_cmd2str(u8 Command, u8 Subcommand) | |||
297 | be NULL if the command/subcommand is not one of those defined in the | 325 | be NULL if the command/subcommand is not one of those defined in the |
298 | CAPI 2.0 standard. | 326 | CAPI 2.0 standard. |
299 | 327 | ||
328 | |||
329 | 7. Debugging | ||
330 | |||
331 | The module kernelcapi has a module parameter showcapimsgs controlling some | ||
332 | debugging output produced by the module. It can only be set when the module is | ||
333 | loaded, via a parameter "showcapimsgs=<n>" to the modprobe command, either on | ||
334 | the command line or in the configuration file. | ||
335 | |||
336 | If the lowest bit of showcapimsgs is set, kernelcapi logs controller and | ||
337 | application up and down events. | ||
338 | |||
339 | In addition, every registered CAPI controller has an associated traceflag | ||
340 | parameter controlling how CAPI messages sent from and to tha controller are | ||
341 | logged. The traceflag parameter is initialized with the value of the | ||
342 | showcapimsgs parameter when the controller is registered, but can later be | ||
343 | changed via the MANUFACTURER_REQ command KCAPI_CMD_TRACE. | ||
344 | |||
345 | If the value of traceflag is non-zero, CAPI messages are logged. | ||
346 | DATA_B3 messages are only logged if the value of traceflag is > 2. | ||
347 | |||
348 | If the lowest bit of traceflag is set, only the command/subcommand and message | ||
349 | length are logged. Otherwise, kernelcapi logs a readable representation of | ||
350 | the entire message. | ||
diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt index c6cf4a3c16e0..61bb645d50e0 100644 --- a/Documentation/networking/pktgen.txt +++ b/Documentation/networking/pktgen.txt | |||
@@ -90,6 +90,11 @@ Examples: | |||
90 | pgset "dstmac 00:00:00:00:00:00" sets MAC destination address | 90 | pgset "dstmac 00:00:00:00:00:00" sets MAC destination address |
91 | pgset "srcmac 00:00:00:00:00:00" sets MAC source address | 91 | pgset "srcmac 00:00:00:00:00:00" sets MAC source address |
92 | 92 | ||
93 | pgset "queue_map_min 0" Sets the min value of tx queue interval | ||
94 | pgset "queue_map_max 7" Sets the max value of tx queue interval, for multiqueue devices | ||
95 | To select queue 1 of a given device, | ||
96 | use queue_map_min=1 and queue_map_max=1 | ||
97 | |||
93 | pgset "src_mac_count 1" Sets the number of MACs we'll range through. | 98 | pgset "src_mac_count 1" Sets the number of MACs we'll range through. |
94 | The 'minimum' MAC is what you set with srcmac. | 99 | The 'minimum' MAC is what you set with srcmac. |
95 | 100 | ||
@@ -101,6 +106,9 @@ Examples: | |||
101 | IPDST_RND, UDPSRC_RND, | 106 | IPDST_RND, UDPSRC_RND, |
102 | UDPDST_RND, MACSRC_RND, MACDST_RND | 107 | UDPDST_RND, MACSRC_RND, MACDST_RND |
103 | MPLS_RND, VID_RND, SVID_RND | 108 | MPLS_RND, VID_RND, SVID_RND |
109 | QUEUE_MAP_RND # queue map random | ||
110 | QUEUE_MAP_CPU # queue map mirrors smp_processor_id() | ||
111 | |||
104 | 112 | ||
105 | pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then | 113 | pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then |
106 | cycle through the port range. | 114 | cycle through the port range. |