About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / networking / timestamping.txt




Custom Search

Based on kernel version 4.13.3. Page generated on 2017-09-23 13:55 EST.

1	
2	1. Control Interfaces
3	
4	The interfaces for receiving network packages timestamps are:
5	
6	* SO_TIMESTAMP
7	  Generates a timestamp for each incoming packet in (not necessarily
8	  monotonic) system time. Reports the timestamp via recvmsg() in a
9	  control message as struct timeval (usec resolution).
10	
11	* SO_TIMESTAMPNS
12	  Same timestamping mechanism as SO_TIMESTAMP, but reports the
13	  timestamp as struct timespec (nsec resolution).
14	
15	* IP_MULTICAST_LOOP + SO_TIMESTAMP[NS]
16	  Only for multicast:approximate transmit timestamp obtained by
17	  reading the looped packet receive timestamp.
18	
19	* SO_TIMESTAMPING
20	  Generates timestamps on reception, transmission or both. Supports
21	  multiple timestamp sources, including hardware. Supports generating
22	  timestamps for stream sockets.
23	
24	
25	1.1 SO_TIMESTAMP:
26	
27	This socket option enables timestamping of datagrams on the reception
28	path. Because the destination socket, if any, is not known early in
29	the network stack, the feature has to be enabled for all packets. The
30	same is true for all early receive timestamp options.
31	
32	For interface details, see `man 7 socket`.
33	
34	
35	1.2 SO_TIMESTAMPNS:
36	
37	This option is identical to SO_TIMESTAMP except for the returned data type.
38	Its struct timespec allows for higher resolution (ns) timestamps than the
39	timeval of SO_TIMESTAMP (ms).
40	
41	
42	1.3 SO_TIMESTAMPING:
43	
44	Supports multiple types of timestamp requests. As a result, this
45	socket option takes a bitmap of flags, not a boolean. In
46	
47	  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, &val, sizeof(val));
48	
49	val is an integer with any of the following bits set. Setting other
50	bit returns EINVAL and does not change the current state.
51	
52	The socket option configures timestamp generation for individual
53	sk_buffs (1.3.1), timestamp reporting to the socket's error
54	queue (1.3.2) and options (1.3.3). Timestamp generation can also
55	be enabled for individual sendmsg calls using cmsg (1.3.4).
56	
57	
58	1.3.1 Timestamp Generation
59	
60	Some bits are requests to the stack to try to generate timestamps. Any
61	combination of them is valid. Changes to these bits apply to newly
62	created packets, not to packets already in the stack. As a result, it
63	is possible to selectively request timestamps for a subset of packets
64	(e.g., for sampling) by embedding an send() call within two setsockopt
65	calls, one to enable timestamp generation and one to disable it.
66	Timestamps may also be generated for reasons other than being
67	requested by a particular socket, such as when receive timestamping is
68	enabled system wide, as explained earlier.
69	
70	SOF_TIMESTAMPING_RX_HARDWARE:
71	  Request rx timestamps generated by the network adapter.
72	
73	SOF_TIMESTAMPING_RX_SOFTWARE:
74	  Request rx timestamps when data enters the kernel. These timestamps
75	  are generated just after a device driver hands a packet to the
76	  kernel receive stack.
77	
78	SOF_TIMESTAMPING_TX_HARDWARE:
79	  Request tx timestamps generated by the network adapter. This flag
80	  can be enabled via both socket options and control messages.
81	
82	SOF_TIMESTAMPING_TX_SOFTWARE:
83	  Request tx timestamps when data leaves the kernel. These timestamps
84	  are generated in the device driver as close as possible, but always
85	  prior to, passing the packet to the network interface. Hence, they
86	  require driver support and may not be available for all devices.
87	  This flag can be enabled via both socket options and control messages.
88	
89	
90	SOF_TIMESTAMPING_TX_SCHED:
91	  Request tx timestamps prior to entering the packet scheduler. Kernel
92	  transmit latency is, if long, often dominated by queuing delay. The
93	  difference between this timestamp and one taken at
94	  SOF_TIMESTAMPING_TX_SOFTWARE will expose this latency independent
95	  of protocol processing. The latency incurred in protocol
96	  processing, if any, can be computed by subtracting a userspace
97	  timestamp taken immediately before send() from this timestamp. On
98	  machines with virtual devices where a transmitted packet travels
99	  through multiple devices and, hence, multiple packet schedulers,
100	  a timestamp is generated at each layer. This allows for fine
101	  grained measurement of queuing delay. This flag can be enabled
102	  via both socket options and control messages.
103	
104	SOF_TIMESTAMPING_TX_ACK:
105	  Request tx timestamps when all data in the send buffer has been
106	  acknowledged. This only makes sense for reliable protocols. It is
107	  currently only implemented for TCP. For that protocol, it may
108	  over-report measurement, because the timestamp is generated when all
109	  data up to and including the buffer at send() was acknowledged: the
110	  cumulative acknowledgment. The mechanism ignores SACK and FACK.
111	  This flag can be enabled via both socket options and control messages.
112	
113	
114	1.3.2 Timestamp Reporting
115	
116	The other three bits control which timestamps will be reported in a
117	generated control message. Changes to the bits take immediate
118	effect at the timestamp reporting locations in the stack. Timestamps
119	are only reported for packets that also have the relevant timestamp
120	generation request set.
121	
122	SOF_TIMESTAMPING_SOFTWARE:
123	  Report any software timestamps when available.
124	
125	SOF_TIMESTAMPING_SYS_HARDWARE:
126	  This option is deprecated and ignored.
127	
128	SOF_TIMESTAMPING_RAW_HARDWARE:
129	  Report hardware timestamps as generated by
130	  SOF_TIMESTAMPING_TX_HARDWARE when available.
131	
132	
133	1.3.3 Timestamp Options
134	
135	The interface supports the options
136	
137	SOF_TIMESTAMPING_OPT_ID:
138	
139	  Generate a unique identifier along with each packet. A process can
140	  have multiple concurrent timestamping requests outstanding. Packets
141	  can be reordered in the transmit path, for instance in the packet
142	  scheduler. In that case timestamps will be queued onto the error
143	  queue out of order from the original send() calls. It is not always
144	  possible to uniquely match timestamps to the original send() calls
145	  based on timestamp order or payload inspection alone, then.
146	
147	  This option associates each packet at send() with a unique
148	  identifier and returns that along with the timestamp. The identifier
149	  is derived from a per-socket u32 counter (that wraps). For datagram
150	  sockets, the counter increments with each sent packet. For stream
151	  sockets, it increments with every byte.
152	
153	  The counter starts at zero. It is initialized the first time that
154	  the socket option is enabled. It is reset each time the option is
155	  enabled after having been disabled. Resetting the counter does not
156	  change the identifiers of existing packets in the system.
157	
158	  This option is implemented only for transmit timestamps. There, the
159	  timestamp is always looped along with a struct sock_extended_err.
160	  The option modifies field ee_data to pass an id that is unique
161	  among all possibly concurrently outstanding timestamp requests for
162	  that socket.
163	
164	
165	SOF_TIMESTAMPING_OPT_CMSG:
166	
167	  Support recv() cmsg for all timestamped packets. Control messages
168	  are already supported unconditionally on all packets with receive
169	  timestamps and on IPv6 packets with transmit timestamp. This option
170	  extends them to IPv4 packets with transmit timestamp. One use case
171	  is to correlate packets with their egress device, by enabling socket
172	  option IP_PKTINFO simultaneously.
173	
174	
175	SOF_TIMESTAMPING_OPT_TSONLY:
176	
177	  Applies to transmit timestamps only. Makes the kernel return the
178	  timestamp as a cmsg alongside an empty packet, as opposed to
179	  alongside the original packet. This reduces the amount of memory
180	  charged to the socket's receive budget (SO_RCVBUF) and delivers
181	  the timestamp even if sysctl net.core.tstamp_allow_data is 0.
182	  This option disables SOF_TIMESTAMPING_OPT_CMSG.
183	
184	SOF_TIMESTAMPING_OPT_STATS:
185	
186	  Optional stats that are obtained along with the transmit timestamps.
187	  It must be used together with SOF_TIMESTAMPING_OPT_TSONLY. When the
188	  transmit timestamp is available, the stats are available in a
189	  separate control message of type SCM_TIMESTAMPING_OPT_STATS, as a
190	  list of TLVs (struct nlattr) of types. These stats allow the
191	  application to associate various transport layer stats with
192	  the transmit timestamps, such as how long a certain block of
193	  data was limited by peer's receiver window.
194	
195	SOF_TIMESTAMPING_OPT_PKTINFO:
196	
197	  Enable the SCM_TIMESTAMPING_PKTINFO control message for incoming
198	  packets with hardware timestamps. The message contains struct
199	  scm_ts_pktinfo, which supplies the index of the real interface which
200	  received the packet and its length at layer 2. A valid (non-zero)
201	  interface index will be returned only if CONFIG_NET_RX_BUSY_POLL is
202	  enabled and the driver is using NAPI. The struct contains also two
203	  other fields, but they are reserved and undefined.
204	
205	SOF_TIMESTAMPING_OPT_TX_SWHW:
206	
207	  Request both hardware and software timestamps for outgoing packets
208	  when SOF_TIMESTAMPING_TX_HARDWARE and SOF_TIMESTAMPING_TX_SOFTWARE
209	  are enabled at the same time. If both timestamps are generated,
210	  two separate messages will be looped to the socket's error queue,
211	  each containing just one timestamp.
212	
213	New applications are encouraged to pass SOF_TIMESTAMPING_OPT_ID to
214	disambiguate timestamps and SOF_TIMESTAMPING_OPT_TSONLY to operate
215	regardless of the setting of sysctl net.core.tstamp_allow_data.
216	
217	An exception is when a process needs additional cmsg data, for
218	instance SOL_IP/IP_PKTINFO to detect the egress network interface.
219	Then pass option SOF_TIMESTAMPING_OPT_CMSG. This option depends on
220	having access to the contents of the original packet, so cannot be
221	combined with SOF_TIMESTAMPING_OPT_TSONLY.
222	
223	
224	1.3.4. Enabling timestamps via control messages
225	
226	In addition to socket options, timestamp generation can be requested
227	per write via cmsg, only for SOF_TIMESTAMPING_TX_* (see Section 1.3.1).
228	Using this feature, applications can sample timestamps per sendmsg()
229	without paying the overhead of enabling and disabling timestamps via
230	setsockopt:
231	
232	  struct msghdr *msg;
233	  ...
234	  cmsg			       = CMSG_FIRSTHDR(msg);
235	  cmsg->cmsg_level	       = SOL_SOCKET;
236	  cmsg->cmsg_type	       = SO_TIMESTAMPING;
237	  cmsg->cmsg_len	       = CMSG_LEN(sizeof(__u32));
238	  *((__u32 *) CMSG_DATA(cmsg)) = SOF_TIMESTAMPING_TX_SCHED |
239					 SOF_TIMESTAMPING_TX_SOFTWARE |
240					 SOF_TIMESTAMPING_TX_ACK;
241	  err = sendmsg(fd, msg, 0);
242	
243	The SOF_TIMESTAMPING_TX_* flags set via cmsg will override
244	the SOF_TIMESTAMPING_TX_* flags set via setsockopt.
245	
246	Moreover, applications must still enable timestamp reporting via
247	setsockopt to receive timestamps:
248	
249	  __u32 val = SOF_TIMESTAMPING_SOFTWARE |
250		      SOF_TIMESTAMPING_OPT_ID /* or any other flag */;
251	  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, &val, sizeof(val));
252	
253	
254	1.4 Bytestream Timestamps
255	
256	The SO_TIMESTAMPING interface supports timestamping of bytes in a
257	bytestream. Each request is interpreted as a request for when the
258	entire contents of the buffer has passed a timestamping point. That
259	is, for streams option SOF_TIMESTAMPING_TX_SOFTWARE will record
260	when all bytes have reached the device driver, regardless of how
261	many packets the data has been converted into.
262	
263	In general, bytestreams have no natural delimiters and therefore
264	correlating a timestamp with data is non-trivial. A range of bytes
265	may be split across segments, any segments may be merged (possibly
266	coalescing sections of previously segmented buffers associated with
267	independent send() calls). Segments can be reordered and the same
268	byte range can coexist in multiple segments for protocols that
269	implement retransmissions.
270	
271	It is essential that all timestamps implement the same semantics,
272	regardless of these possible transformations, as otherwise they are
273	incomparable. Handling "rare" corner cases differently from the
274	simple case (a 1:1 mapping from buffer to skb) is insufficient
275	because performance debugging often needs to focus on such outliers.
276	
277	In practice, timestamps can be correlated with segments of a
278	bytestream consistently, if both semantics of the timestamp and the
279	timing of measurement are chosen correctly. This challenge is no
280	different from deciding on a strategy for IP fragmentation. There, the
281	definition is that only the first fragment is timestamped. For
282	bytestreams, we chose that a timestamp is generated only when all
283	bytes have passed a point. SOF_TIMESTAMPING_TX_ACK as defined is easy to
284	implement and reason about. An implementation that has to take into
285	account SACK would be more complex due to possible transmission holes
286	and out of order arrival.
287	
288	On the host, TCP can also break the simple 1:1 mapping from buffer to
289	skbuff as a result of Nagle, cork, autocork, segmentation and GSO. The
290	implementation ensures correctness in all cases by tracking the
291	individual last byte passed to send(), even if it is no longer the
292	last byte after an skbuff extend or merge operation. It stores the
293	relevant sequence number in skb_shinfo(skb)->tskey. Because an skbuff
294	has only one such field, only one timestamp can be generated.
295	
296	In rare cases, a timestamp request can be missed if two requests are
297	collapsed onto the same skb. A process can detect this situation by
298	enabling SOF_TIMESTAMPING_OPT_ID and comparing the byte offset at
299	send time with the value returned for each timestamp. It can prevent
300	the situation by always flushing the TCP stack in between requests,
301	for instance by enabling TCP_NODELAY and disabling TCP_CORK and
302	autocork.
303	
304	These precautions ensure that the timestamp is generated only when all
305	bytes have passed a timestamp point, assuming that the network stack
306	itself does not reorder the segments. The stack indeed tries to avoid
307	reordering. The one exception is under administrator control: it is
308	possible to construct a packet scheduler configuration that delays
309	segments from the same stream differently. Such a setup would be
310	unusual.
311	
312	
313	2 Data Interfaces
314	
315	Timestamps are read using the ancillary data feature of recvmsg().
316	See `man 3 cmsg` for details of this interface. The socket manual
317	page (`man 7 socket`) describes how timestamps generated with
318	SO_TIMESTAMP and SO_TIMESTAMPNS records can be retrieved.
319	
320	
321	2.1 SCM_TIMESTAMPING records
322	
323	These timestamps are returned in a control message with cmsg_level
324	SOL_SOCKET, cmsg_type SCM_TIMESTAMPING, and payload of type
325	
326	struct scm_timestamping {
327		struct timespec ts[3];
328	};
329	
330	The structure can return up to three timestamps. This is a legacy
331	feature. At least one field is non-zero at any time. Most timestamps
332	are passed in ts[0]. Hardware timestamps are passed in ts[2].
333	
334	ts[1] used to hold hardware timestamps converted to system time.
335	Instead, expose the hardware clock device on the NIC directly as
336	a HW PTP clock source, to allow time conversion in userspace and
337	optionally synchronize system time with a userspace PTP stack such
338	as linuxptp. For the PTP clock API, see Documentation/ptp/ptp.txt.
339	
340	Note that if the SO_TIMESTAMP or SO_TIMESTAMPNS option is enabled
341	together with SO_TIMESTAMPING using SOF_TIMESTAMPING_SOFTWARE, a false
342	software timestamp will be generated in the recvmsg() call and passed
343	in ts[0] when a real software timestamp is missing. This happens also
344	on hardware transmit timestamps.
345	
346	2.1.1 Transmit timestamps with MSG_ERRQUEUE
347	
348	For transmit timestamps the outgoing packet is looped back to the
349	socket's error queue with the send timestamp(s) attached. A process
350	receives the timestamps by calling recvmsg() with flag MSG_ERRQUEUE
351	set and with a msg_control buffer sufficiently large to receive the
352	relevant metadata structures. The recvmsg call returns the original
353	outgoing data packet with two ancillary messages attached.
354	
355	A message of cm_level SOL_IP(V6) and cm_type IP(V6)_RECVERR
356	embeds a struct sock_extended_err. This defines the error type. For
357	timestamps, the ee_errno field is ENOMSG. The other ancillary message
358	will have cm_level SOL_SOCKET and cm_type SCM_TIMESTAMPING. This
359	embeds the struct scm_timestamping.
360	
361	
362	2.1.1.2 Timestamp types
363	
364	The semantics of the three struct timespec are defined by field
365	ee_info in the extended error structure. It contains a value of
366	type SCM_TSTAMP_* to define the actual timestamp passed in
367	scm_timestamping.
368	
369	The SCM_TSTAMP_* types are 1:1 matches to the SOF_TIMESTAMPING_*
370	control fields discussed previously, with one exception. For legacy
371	reasons, SCM_TSTAMP_SND is equal to zero and can be set for both
372	SOF_TIMESTAMPING_TX_HARDWARE and SOF_TIMESTAMPING_TX_SOFTWARE. It
373	is the first if ts[2] is non-zero, the second otherwise, in which
374	case the timestamp is stored in ts[0].
375	
376	
377	2.1.1.3 Fragmentation
378	
379	Fragmentation of outgoing datagrams is rare, but is possible, e.g., by
380	explicitly disabling PMTU discovery. If an outgoing packet is fragmented,
381	then only the first fragment is timestamped and returned to the sending
382	socket.
383	
384	
385	2.1.1.4 Packet Payload
386	
387	The calling application is often not interested in receiving the whole
388	packet payload that it passed to the stack originally: the socket
389	error queue mechanism is just a method to piggyback the timestamp on.
390	In this case, the application can choose to read datagrams with a
391	smaller buffer, possibly even of length 0. The payload is truncated
392	accordingly. Until the process calls recvmsg() on the error queue,
393	however, the full packet is queued, taking up budget from SO_RCVBUF.
394	
395	
396	2.1.1.5 Blocking Read
397	
398	Reading from the error queue is always a non-blocking operation. To
399	block waiting on a timestamp, use poll or select. poll() will return
400	POLLERR in pollfd.revents if any data is ready on the error queue.
401	There is no need to pass this flag in pollfd.events. This flag is
402	ignored on request. See also `man 2 poll`.
403	
404	
405	2.1.2 Receive timestamps
406	
407	On reception, there is no reason to read from the socket error queue.
408	The SCM_TIMESTAMPING ancillary data is sent along with the packet data
409	on a normal recvmsg(). Since this is not a socket error, it is not
410	accompanied by a message SOL_IP(V6)/IP(V6)_RECVERROR. In this case,
411	the meaning of the three fields in struct scm_timestamping is
412	implicitly defined. ts[0] holds a software timestamp if set, ts[1]
413	is again deprecated and ts[2] holds a hardware timestamp if set.
414	
415	
416	3. Hardware Timestamping configuration: SIOCSHWTSTAMP and SIOCGHWTSTAMP
417	
418	Hardware time stamping must also be initialized for each device driver
419	that is expected to do hardware time stamping. The parameter is defined in
420	/include/linux/net_tstamp.h as:
421	
422	struct hwtstamp_config {
423		int flags;	/* no flags defined right now, must be zero */
424		int tx_type;	/* HWTSTAMP_TX_* */
425		int rx_filter;	/* HWTSTAMP_FILTER_* */
426	};
427	
428	Desired behavior is passed into the kernel and to a specific device by
429	calling ioctl(SIOCSHWTSTAMP) with a pointer to a struct ifreq whose
430	ifr_data points to a struct hwtstamp_config. The tx_type and
431	rx_filter are hints to the driver what it is expected to do. If
432	the requested fine-grained filtering for incoming packets is not
433	supported, the driver may time stamp more than just the requested types
434	of packets.
435	
436	Drivers are free to use a more permissive configuration than the requested
437	configuration. It is expected that drivers should only implement directly the
438	most generic mode that can be supported. For example if the hardware can
439	support HWTSTAMP_FILTER_V2_EVENT, then it should generally always upscale
440	HWTSTAMP_FILTER_V2_L2_SYNC_MESSAGE, and so forth, as HWTSTAMP_FILTER_V2_EVENT
441	is more generic (and more useful to applications).
442	
443	A driver which supports hardware time stamping shall update the struct
444	with the actual, possibly more permissive configuration. If the
445	requested packets cannot be time stamped, then nothing should be
446	changed and ERANGE shall be returned (in contrast to EINVAL, which
447	indicates that SIOCSHWTSTAMP is not supported at all).
448	
449	Only a processes with admin rights may change the configuration. User
450	space is responsible to ensure that multiple processes don't interfere
451	with each other and that the settings are reset.
452	
453	Any process can read the actual configuration by passing this
454	structure to ioctl(SIOCGHWTSTAMP) in the same way.  However, this has
455	not been implemented in all drivers.
456	
457	/* possible values for hwtstamp_config->tx_type */
458	enum {
459		/*
460		 * no outgoing packet will need hardware time stamping;
461		 * should a packet arrive which asks for it, no hardware
462		 * time stamping will be done
463		 */
464		HWTSTAMP_TX_OFF,
465	
466		/*
467		 * enables hardware time stamping for outgoing packets;
468		 * the sender of the packet decides which are to be
469		 * time stamped by setting SOF_TIMESTAMPING_TX_SOFTWARE
470		 * before sending the packet
471		 */
472		HWTSTAMP_TX_ON,
473	};
474	
475	/* possible values for hwtstamp_config->rx_filter */
476	enum {
477		/* time stamp no incoming packet at all */
478		HWTSTAMP_FILTER_NONE,
479	
480		/* time stamp any incoming packet */
481		HWTSTAMP_FILTER_ALL,
482	
483		/* return value: time stamp all packets requested plus some others */
484		HWTSTAMP_FILTER_SOME,
485	
486		/* PTP v1, UDP, any kind of event packet */
487		HWTSTAMP_FILTER_PTP_V1_L4_EVENT,
488	
489		/* for the complete list of values, please check
490		 * the include file /include/linux/net_tstamp.h
491		 */
492	};
493	
494	3.1 Hardware Timestamping Implementation: Device Drivers
495	
496	A driver which supports hardware time stamping must support the
497	SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with
498	the actual values as described in the section on SIOCSHWTSTAMP.  It
499	should also support SIOCGHWTSTAMP.
500	
501	Time stamps for received packets must be stored in the skb. To get a pointer
502	to the shared time stamp structure of the skb call skb_hwtstamps(). Then
503	set the time stamps in the structure:
504	
505	struct skb_shared_hwtstamps {
506		/* hardware time stamp transformed into duration
507		 * since arbitrary point in time
508		 */
509		ktime_t	hwtstamp;
510	};
511	
512	Time stamps for outgoing packets are to be generated as follows:
513	- In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)
514	  is set no-zero. If yes, then the driver is expected to do hardware time
515	  stamping.
516	- If this is possible for the skb and requested, then declare
517	  that the driver is doing the time stamping by setting the flag
518	  SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with
519	
520	      skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
521	
522	  You might want to keep a pointer to the associated skb for the next step
523	  and not free the skb. A driver not supporting hardware time stamping doesn't
524	  do that. A driver must never touch sk_buff::tstamp! It is used to store
525	  software generated time stamps by the network subsystem.
526	- Driver should call skb_tx_timestamp() as close to passing sk_buff to hardware
527	  as possible. skb_tx_timestamp() provides a software time stamp if requested
528	  and hardware timestamping is not possible (SKBTX_IN_PROGRESS not set).
529	- As soon as the driver has sent the packet and/or obtained a
530	  hardware time stamp for it, it passes the time stamp back by
531	  calling skb_hwtstamp_tx() with the original skb, the raw
532	  hardware time stamp. skb_hwtstamp_tx() clones the original skb and
533	  adds the timestamps, therefore the original skb has to be freed now.
534	  If obtaining the hardware time stamp somehow fails, then the driver
535	  should not fall back to software time stamping. The rationale is that
536	  this would occur at a later time in the processing pipeline than other
537	  software time stamping and therefore could lead to unexpected deltas
538	  between time stamps.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.