Documentationusb\usb\mon.txt

 Chinese translated version of Documentationusb\usb\mon.txt

If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.

Chinese maintainer: majg <[e-mail]>
---------------------------------------------------------------------
Documentationusb\usb\mon.txt 的中文翻译

如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。

中文版维护者： 马建刚  majg <[e-mail]>
中文版翻译者： 马建刚  majg <[e-mail]>
中文版校译者： 马建刚  majg <[e-mail]>

 

 

以下为正文
---------------------------------------------------------------------
  1 * Introduction
-绪言
  2
  3 The name "usbmon" in lowercase refers to a facility in kernel which is
  4 used to collect traces of I/O on the USB bus. This function is analogous
  5 to a packet socket used by network monitoring tools such as tcpdump(1)
  6 or Ethereal. Similarly, it is expected that a tool such as usbdump or
  7 USBMon (with uppercase letters) is used to examine raw traces produced
  8 by usbmon.
-小写的名称的“usbmon”是指在内核设施是用来收集在USB总线上的I/ O的痕迹。
此功能类似于一包插座所使用的网络监控工具如tcpdump(1) or Ethereal. 。同样地，
预期（大写字母）usbdump或USBMon的一个工具，如用于检查原始由usbmon生产的痕迹。
  9
 10 The usbmon reports requests made by peripheral-specific drivers to Host
 11 Controller Drivers (HCD). So, if HCD is buggy, the traces reported by
 12 usbmon may not correspond to bus transactions precisely. This is the same
 13 situation as with tcpdump.
-usbmon报告周边特定的驱动程序，主机控制器驱动程序（HCD）的请求。所以，
如果HCD是马车的痕迹由usbmon报告可能不符合精确总线交易。这是相同的情况
下用tcpdump。
 14
 15 Two APIs are currently implemented: "text" and "binary". The binary API
 16 is available through a character device in /dev namespace and is an ABI.
 17 The text API is deprecated since 2.6.35, but available for convenience.
 18
 19 * How to use usbmon to collect raw text traces
-怎样使用usbmon收集原始文本的痕迹
 20
 21 Unlike the packet socket, usbmon has an interface which provides traces
 22 in a text format. This is used for two purposes. First, it serves as a
 23 common trace exchange format for tools while more sophisticated formats
 24 are finalized. Second, humans can read it in case tools are not available.
-不同的是数据包的套接字中，usbmon有一个接口，它提供了以文本格式的痕迹。
这是用于两个目的。首先，它作为一个共同的跟踪工具交换格式，而更复杂的格
式敲定。其次，人类可以阅读它的情况下工具所不具备的。
 25
 26 To collect a raw text trace, execute following steps.
-收集原始文本跟踪，请执行以下步骤。
 27
 28 1. Prepare
 29
 30 Mount debugfs (it has to be enabled in your kernel configuration), and
 31 load the usbmon module (if built as module). The second step is skipped
 32 if usbmon is built into the kernel.
-大多数的debugfs（它必须在内核配置启用），并加载的usbmon模块（内置模块）。
如果usbmon构建到内核中，第二步骤被跳过。
 33
 34 # mount -t debugfs none_debugs /sys/kernel/debug
 35 # modprobe usbmon
 36 #
 37
 38 Verify that bus sockets are present.
-验证总线插座。
 39
 40 # ls /sys/kernel/debug/usb/usbmon
 41 0s  0u  1s  1t  1u  2s  2t  2u  3s  3t  3u  4s  4t  4u
 42 #
 43
 44 Now you can choose to either use the socket '0u' (to capture packets on all
 45 buses), and skip to step #3, or find the bus used by your device with step #2.
 46 This allows to filter away annoying devices that talk continuously.
-现在，您可以选择使用插座'0 U'（所有总线上捕获数据包），跳到第3步，
或与第2步中找到您的设备使用的总线。这使得过滤远离恼人的设备。
 47
 48 2. Find which bus connects to the desired device
-查找总线连接到所需的设备
 49
 50 Run "cat /sys/kernel/debug/usb/devices", and find the T-line which corresponds
 51 to the device. Usually you do it by looking for the vendor string. If you have
 52 many similar devices, unplug one and compare the two
 53 /sys/kernel/debug/usb/devices outputs. The T-line will have a bus number.
 54 Example:
 55
 56 T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
 57 D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
 58 P:  Vendor=0557 ProdID=2004 Rev= 1.00
 59 S:  Manufacturer=ATEN
 60 S:  Product=UC100KM V2.00
 61
 62 "Bus=03" means it's bus 3. Alternatively, you can look at the output from
 63 "lsusb" and get the bus number from the appropriate line. Example:
 64
 65 Bus 003 Device 002: ID 0557:2004 ATEN UC100KM V2.00
 66
 67 3. Start 'cat'
 68
 69 # cat /sys/kernel/debug/usb/usbmon/3u > /tmp/1.mon.out
 70
 71 to listen on a single bus, otherwise, to listen on all buses, type:
 72
 73 # cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out
 74
 75 This process will be reading until killed. Naturally, the output can be
 76 redirected to a desirable location. This is preferred, because it is going
 77 to be quite long.
-这个过程将被读取，直到被杀。当然，输出可以被重定向到一个理想的位置。
这是优选的，因为这将是相当长的。
 78
 79 4. Perform the desired operation on the USB bus
-在USB总线上执行所需的操作
 80
 81 This is where you do something that creates the traffic: plug in a flash key,
 82 copy files, control a webcam, etc.
-这是你做的东西，创造交通：插在闪光灯键，拷贝文件，控制摄像头等。
 83
 84 5. Kill cat
 85
 86 Usually it's done with a keyboard interrupt (Control-C).
-一般做一个键盘中断（控制-C）。
 87
 88 At this point the output file (/tmp/1.mon.out in this example) can be saved,
 89 sent by e-mail, or inspected with a text editor. In the last case make sure
 90 that the file size is not excessive for your favourite editor.
-在这一点上，可以保存输出文件（/ tmp/1.mon.out在这个例子中），通过e-mail发送，
或用文本编辑器检查。在过去的情况下，确保为您最喜爱的编辑器，文件大小也不为过。
 91
 92 * Raw text data format
-原始文本数据格式
 93
 94 Two formats are supported currently: the original, or '1t' format, and
 95 the '1u' format. The '1t' format is deprecated in kernel 2.6.21. The '1u'
 96 format adds a few fields, such as ISO frame descriptors, interval, etc.
 97 It produces slightly longer lines, but otherwise is a perfect superset
 98 of '1t' format.
-目前支持两种格式：原始，或'1 T'格式，和“U”的格式。 “T”格式已过时的2.6.21内核。
“U”格式增加了一些领域，如ISO框架描述，间隔等生产线略长，但在其他方面是一个完美的超'1 T'格式。
 99
100 If it is desired to recognize one from the other in a program, look at the
101 "address" word (see below), where '1u' format adds a bus number. If 2 colons
102 are present, it's the '1t' format, otherwise '1u'.
-如果需要承认一个从其他程序中的“地址”字（见下文），其中'1 U'格式增加了总线数。
如果2冒号目前，它的“T”格式，否则'1 U'。
103
104 Any text format data consists of a stream of events, such as URB submission,
105 URB callback, submission error. Every event is a text line, which consists
106 of whitespace separated words. The number or position of words may depend
107 on the event type, but there is a set of words, common for all types.
-由任何文本格式的数据流的事件，如URB提交URB回调，提交错误。每一个事件是一个文本行，
由空格分隔的单词。字的数目或位置可能依赖于事件类型，但有一组的话，常用于所有种类的。
108
109 Here is the list of words, from left to right:
-下面是单词的列表，从左至右：
110
111 - URB Tag. This is used to identify URBs, and is normally an in-kernel address
112   of the URB structure in hexadecimal, but can be a sequence number or any
113   other unique string, within reason.
114
115 - Timestamp in microseconds, a decimal number. The timestamp's resolution
116   depends on available clock, and so it can be much worse than a microsecond
117   (if the implementation uses jiffies, for example).
118
119 - Event Type. This type refers to the format of the event, not URB type.
120   Available types are: S - submission, C - callback, E - submission error.
121
122 - "Address" word (formerly a "pipe"). It consists of four fields, separated by
123   colons: URB type and direction, Bus number, Device address, Endpoint number.
124   Type and direction are encoded with two bytes in the following manner:
125     Ci Co   Control input and output
126     Zi Zo   Isochronous input and output
127     Ii Io   Interrupt input and output
128     Bi Bo   Bulk input and output
129   Bus number, Device address, and Endpoint are decimal numbers, but they may
130   have leading zeros, for the sake of human readers.
131
132 - URB Status word. This is either a letter, or several numbers separated
133   by colons: URB status, interval, start frame, and error count. Unlike the
134   "address" word, all fields save the status are optional. Interval is printed
135   only for interrupt and isochronous URBs. Start frame is printed only for
136   isochronous URBs. Error count is printed only for isochronous callback
137   events.
138
139   The status field is a decimal number, sometimes negative, which represents
140   a "status" field of the URB. This field makes no sense for submissions, but
141   is present anyway to help scripts with parsing. When an error occurs, the
142   field contains the error code.
143
144   In case of a submission of a Control packet, this field contains a Setup Tag
145   instead of an group of numbers. It is easy to tell whether the Setup Tag is
146   present because it is never a number. Thus if scripts find a set of numbers
147   in this word, they proceed to read Data Length (except for isochronous URBs).
148   If they find something else, like a letter, they read the setup packet before
149   reading the Data Length or isochronous descriptors.
150
151 - Setup packet, if present, consists of 5 words: one of each for bmRequestType,
152   bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0.
153   These words are safe to decode if Setup Tag was 's'. Otherwise, the setup
154   packet was present, but not captured, and the fields contain filler.
155
156 - Number of isochronous frame descriptors and descriptors themselves.
157   If an Isochronous transfer event has a set of descriptors, a total number
158   of them in an URB is printed first, then a word per descriptor, up to a
159   total of 5. The word consists of 3 colon-separated decimal numbers for
160   status, offset, and length respectively. For submissions, initial length
161   is reported. For callbacks, actual length is reported.
162
163 - Data Length. For submissions, this is the requested length. For callbacks,
164   this is the actual length.
165
166 - Data tag. The usbmon may not always capture data, even if length is nonzero.
167   The data words are present only if this tag is '='.
168
169 - Data words follow, in big endian hexadecimal format. Notice that they are
170   not machine words, but really just a byte stream split into words to make
171   it easier to read. Thus, the last word may contain from one to four bytes.
172   The length of collected data is limited and can be less than the data length
173   reported in the Data Length word. In the case of an Isochronous input (Zi)
174   completion where the received data is sparse in the buffer, the length of
175   the collected data can be greater than the Data Length value (because Data
176   Length counts only the bytes that were received whereas the Data words
177   contain the entire transfer buffer).
178
179 Examples:
180
181 An input control transfer to get a port status.
182
183 d5ea89a0 3575914555 S Ci:1:001:0 s a3 00 0000 0003 0004 4 <
184 d5ea89a0 3575914560 C Ci:1:001:0 0 4 = 01050000
185
186 An output bulk transfer to send a SCSI command 0x28 (READ_10) in a 31-byte
187 Bulk wrapper to a storage device at address 5:
188
189 dd65f0e8 4128379752 S Bo:1:005:2 -115 31 = 55534243 ad000000 00800000 80010a28 20000000 20000040 00000000 000000
190 dd65f0e8 4128379808 C Bo:1:005:2 0 31 >
191
192 * Raw binary format and API
-原始二进制格式和API
193
194 The overall architecture of the API is about the same as the one above,
195 only the events are delivered in binary format. Each event is sent in
196 the following structure (its name is made up, so that we can refer to it):
-整体体系结构的API是大约相同的，如上图所示，只有交付事件为二进制格式。
每个事件都发送以下结构（它的名字，这样我们可以参考）：
197
198 struct usbmon_packet {
199         u64 id;                 /*  0: URB ID - from submission to callback */
200         unsigned char type;     /*  8: Same as text; extensible. */
201         unsigned char xfer_type; /*    ISO (0), Intr, Control, Bulk (3) */
202         unsigned char epnum;    /*     Endpoint number and transfer direction */
203         unsigned char devnum;   /*     Device address */
204         u16 busnum;             /* 12: Bus number */
205         char flag_setup;        /* 14: Same as text */
206         char flag_data;         /* 15: Same as text; Binary zero is OK. */
207         s64 ts_sec;             /* 16: gettimeofday */
208         s32 ts_usec;            /* 24: gettimeofday */
209         int status;             /* 28: */
210         unsigned int length;    /* 32: Length of data (submitted or actual) */
211         unsigned int len_cap;   /* 36: Delivered length */
212         union {                 /* 40: */
213                 unsigned char setup[SETUP_LEN]; /* Only for Control S-type */
214                 struct iso_rec {                /* Only for ISO */
215                         int error_count;
216                         int numdesc;
217                 } iso;
218         } s;
219         int interval;           /* 48: Only for Interrupt and ISO */
220         int start_frame;        /* 52: For ISO */
221         unsigned int xfer_flags; /* 56: copy of URB's transfer_flags */
222         unsigned int ndesc;     /* 60: Actual number of ISO descriptors */
223 };                              /* 64 total length */
224
225 These events can be received from a character device by reading with read(2),
226 with an ioctl(2), or by accessing the buffer with mmap. However, read(2)
227 only returns first 48 bytes for compatibility reasons.
228
229 The character device is usually called /dev/usbmonN, where N is the USB bus
230 number. Number zero (/dev/usbmon0) is special and means "all buses".
231 Note that specific naming policy is set by your Linux distribution.
232
233 If you create /dev/usbmon0 by hand, make sure that it is owned by root
234 and has mode 0600. Otherwise, unpriviledged users will be able to snoop
235 keyboard traffic.
236
237 The following ioctl calls are available, with MON_IOC_MAGIC 0x92:
238
239  MON_IOCQ_URB_LEN, defined as _IO(MON_IOC_MAGIC, 1)
240
241 This call returns the length of data in the next event. Note that majority of
242 events contain no data, so if this call returns zero, it does not mean that
243 no events are available.
-这个调用返回的长度在下一事件中的数据。请注意，大多数的事件不包含任何数据，
因此，如果这个调用返回零，它并不意味着没有事件。
244
245  MON_IOCG_STATS, defined as _IOR(MON_IOC_MAGIC, 3, struct mon_bin_stats)
246
247 The argument is a pointer to the following structure:
-该参数是一个指向以下结构：
248
249 struct mon_bin_stats {
250         u32 queued;
251         u32 dropped;
252 };
253
254 The member "queued" refers to the number of events currently queued in the
255 buffer (and not to the number of events processed since the last reset).
-"queued" 的构件是指当前排队的缓冲区中的（而不是自上次复位处理的事件的数目）的事件的数量。
256
257 The member "dropped" is the number of events lost since the last call
258 to MON_IOCG_STATS.
- "dropped"的成员，是数量失去了自上次调用MON_IOCG_STATS的事件。
259
260  MON_IOCT_RING_SIZE, defined as _IO(MON_IOC_MAGIC, 4)
261
262 This call sets the buffer size. The argument is the size in bytes.
263 The size may be rounded down to the next chunk (or page). If the requested
264 size is out of [unspecified] bounds for this kernel, the call fails with
265 -EINVAL.
266
267  MON_IOCQ_RING_SIZE, defined as _IO(MON_IOC_MAGIC, 5)
268
269 This call returns the current size of the buffer in bytes.
-此调用返回当前缓冲区的字节大小。
270
271  MON_IOCX_GET, defined as _IOW(MON_IOC_MAGIC, 6, struct mon_get_arg)
272  MON_IOCX_GETX, defined as _IOW(MON_IOC_MAGIC, 10, struct mon_get_arg)
273
274 These calls wait for events to arrive if none were in the kernel buffer,
275 then return the first event. The argument is a pointer to the following
276 structure:
-这些呼叫等待事件到达，如果没有在内核缓冲区，然后返回的第一个事件。
该参数是一个指向以下结构：
277
278 struct mon_get_arg {
279         struct usbmon_packet *hdr;
280         void *data;
281         size_t alloc;           /* Length of data (can be zero) */
282 };
283
284 Before the call, hdr, data, and alloc should be filled. Upon return, the area
285 pointed by hdr contains the next event structure, and the data buffer contains
286 the data, if any. The event is removed from the kernel buffer.
-在通话之前，HDR，数据和alloc应予填补。返回时，指向的区域hdr的包含下一个事件结构，
数据缓冲区中包含的数据，如果有的话。本次活动是从内核缓冲区中删除。
287
288 The MON_IOCX_GET copies 48 bytes to hdr area, MON_IOCX_GETX copies 64 bytes.
289
290  MON_IOCX_MFETCH, defined as _IOWR(MON_IOC_MAGIC, 7, struct mon_mfetch_arg)
291
292 This ioctl is primarily used when the application accesses the buffer
293 with mmap(2). Its argument is a pointer to the following structure:
294
295 struct mon_mfetch_arg {
296         uint32_t *offvec;       /* Vector of events fetched */
297         uint32_t nfetch;        /* Number of events to fetch (out: fetched) */
298         uint32_t nflush;        /* Number of events to flush */
299 };
300
301 The ioctl operates in 3 stages.
-ioctl的工作分3个阶段。
302
303 First, it removes and discards up to nflush events from the kernel buffer.
304 The actual number of events discarded is returned in nflush.
-首先，它会删除并丢弃事件从内核缓冲区刷新。 fflush的被丢弃的事件中返回的实际数量。
305
306 Second, it waits for an event to be present in the buffer, unless the pseudo-
307 device is open with O_NONBLOCK.
-其次，它会等待一个事件，目前在缓冲区中，除非伪设备打开O_NONBLOCK。
308
309 Third, it extracts up to nfetch offsets into the mmap buffer, and stores
310 them into the offvec. The actual number of event offsets is stored into
311 the nfetch.
-第三，它提取取到的mmap缓冲区的偏移，并把它们存储到offvec。
事件的偏移量的实际数目，存储到nfetch。
312
313  MON_IOCH_MFLUSH, defined as _IO(MON_IOC_MAGIC, 8)
314
315 This call removes a number of events from the kernel buffer. Its argument
316 is the number of events to remove. If the buffer contains fewer events
317 than requested, all events present are removed, and no error is reported.
318 This works when no events are available too.
-此调用删除的事件数量从内核缓冲区。它的参数是要删除的事件。如果缓冲区中包含
比要求较少的事件，所有的事件目前被拆除，并报告任何错误。这没有异常事件时也可。
319
320  FIONBIO
321
322 The ioctl FIONBIO may be implemented in the future, if there's a need.
-可能被实施的ioctl FIONBIO的，在未来，如果有需要。
323
324 In addition to ioctl(2) and read(2), the special file of binary API can
325 be polled with select(2) and poll(2). But lseek(2) does not work.
-二进制API的特殊文件的ioctl（2）和read（2）此外，可拉选择（2）和民意调查（2）。但使用lseek（2）不工作。
326
327 * Memory-mapped access of the kernel buffer for the binary API
-内核缓冲区中的内存映射访问二进制API
328
329 The basic idea is simple:
-基本思想很简单：
330
331 To prepare, map the buffer by getting the current size, then using mmap(2).
332 Then, execute a loop similar to the one written in pseudo-code below:
-要准备，缓冲区映射得到的电流大小，当使用mmap（2）。然后，执行下面的伪代码写在一个类似的循环：
333
334    struct mon_mfetch_arg fetch;
335    struct usbmon_packet *hdr;
336    int nflush = 0;
337    for (;;) {
338       fetch.offvec = vec; // Has N 32-bit words
339       fetch.nfetch = N;   // Or less than N
340       fetch.nflush = nflush;
341       ioctl(fd, MON_IOCX_MFETCH, &fetch);   // Process errors, too
342       nflush = fetch.nfetch;       // This many packets to flush when done
343       for (i = 0; i < nflush; i++) {
344          hdr = (struct ubsmon_packet *) &mmap_area[vec[i]];
345          if (hdr->type == '@')     // Filler packet
346             continue;
347          caddr_t data = &mmap_area[vec[i]] + 64;
348          process_packet(hdr, data);
349       }
350    }
351
352 Thus, the main idea is to execute only one ioctl per N events.
-因此，主要的想法是执行只有一个的ioctl每N个事件。
353
354 Although the buffer is circular, the returned headers and data do not cross
355 the end of the buffer, so the above pseudo-code does not need any gathering.
-缓冲区虽然是圆形的，返回的头和数据不越过缓冲区结尾，所以上面的伪代码不需要任何聚会。