怎样在VMware虚拟机中使用安装并设置Ubuntu系统_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
21页免费24页免费17页免费22页免费2页免费19页免费45页1下载券4页免费6页免费2页免费
喜欢此文档的还喜欢38页1下载券3页1下载券140页1下载券61页1下载券92页1下载券
怎样在VMware虚拟机中使用安装并设置Ubuntu系统|怎​样​在​V​M​w​a​r​e​虚​拟​机​中​使​用​安​装​并​设​置​U​b​u​n​t​u​系​统
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
你可能喜欢Xenomai 进程间通信方式分成Xenomai域内的IPC以及Xenomai域和Linux域之间的IPC,
目前采用的rtipc（RTDM驱动）的方式，主要是给用户空间提供socket接口，实时应用
通过调用对应的接口可以避免切换到Linux域而导致实时性降低。rtipc对应了三个协议：
XDDP (Xenomai域和Linux域之间的IPC）
IDDP和BUFP (Xenomai域内的IPC)
另外，原有的RT_PIPE机制仍旧支持，但从Xenomai 3开始就不支持了。
In the wake of a recent discussion about Xenomai 3, the requirement to
find a substitute for the native message pipes interface (i.e. RT_PIPE)
was pointed out.
The real-time side of this new interface would have to be available from
kernel space to RTDM drivers as well, so that people adopting a clean
split model like RTDM-drivers &-& userland applications, would not be
left in the cold, with no replacement for the legacy RT_PIPE API in
kernel space, which will be phased out in Xenomai 3.
This question, and a few others, may have found an answer with the
recent merging of the so-called RTIPC framework, for Xenomai 2.5.x.
RTIPC is an RTDM-based &meta-driver&, on top of which one may stack
protocol drivers, exporting a socket interface to the real-time users,
running in primary mode within the Xenomai domain. The point of RTIPC
being precisely that such users won't want to leave the real-time mode
for sending/receiving data to/from other destinations/sources.
So far, I have merged three protocols along with the RTIPC framework,
namely XDDP, IDDP and BUFP.
* XDDP stands for &cross-domain datagram protocol&, i.e. to exchange
datagrams between the Xenomai (primary) real-time domain, and the Linux
realm. This is what the message pipe fans may want to have a look at.
Basically, it connects a real-time RTDM socket to one of the /dev/rtp*
pseudo-devices. The network port used on the socket side matches the
minor device number used on the non RT side. The added bonus of XDDP is
that people relying on the POSIX skin may now have access to the message
pipe feature, without dragging in bits of the native skin API for that
* IDDP stands for &intra-domain datagram protocol&, i.e. a
Xenomai-to-Xenomai real-time datagram channel. This protocol may not be
as flexible as POSIX message queues (does not support message priority
but does out-of-bound sending though), but exports a socket interface,
which is surely better for your brain than mq_*() (ask Gilles). The
basic idea behind it is that anything you could do based on AF_UNIX
sockets in the Linux realm, should be (mostly) doable with AF_RTIPC+IDDP
in the Xenomai domain. However, we use numeric port numbers or label
strings, and not socket paths to bind sockets in the Xenomai namespace.
* BUFP stands for &buffer protocol&, probably the most naive of all, but
likely the best fit when you don't care for message boundaries, and just
want an efficient IPC to send a byte stream from a producer to a
consumer thread, without leaving the Xenomai domain. This protocol is
the exact equivalent of the RT_BUFFER API that came to light earlier in
the 2.5.x series, but again, exporting a socket interface to the
real-time application.
The fact that all RTIPC protocols are RTDM-based, means that one can
reach the socket API from kernel space as well, using the inter-driver
RTDM interface, see:
参考示例：
&* Real-time Xenomai threads and regular Linux threads may want to
&* exchange data in a way that does not require the former to leave
&* the real-time domain (i.e. secondary mode). Message pipes - as
&* implemented by the RTDM-based XDDP protocol - are provided for this
&* purpose.
&* On the Linux domain side, pseudo-device files named /dev/rtp&minor&
&* give regular POSIX threads access to non real-time communication
&* endpoints, via the standard character-based I/O interface. On the
&* Xenomai domain side, sockets may be bound to XDDP ports, which act
&* as proxies to send and receive data to/from the associated
&* pseudo-device files. Ports and pseudo-device minor numbers are
&* paired, meaning that e.g. port 7 will proxy the traffic for
&* /dev/rtp7. Therefore, port numbers may range from 0 to
&* CONFIG_XENO_OPT_PIPE_NRDEV - 1.
&* All data sent through a bound/connected XDDP socket via sendto(2) or
&* write(2) will be passed to the peer endpoint in the Linux domain,
&* and made available for reading via the standard read(2) system
&* call. Conversely, all data sent using write(2) through the non
&* real-time endpoint will be conveyed to the real-time socket
&* endpoint, and made available to the recvfrom(2) or read(2) system
其他相关的说明：
XDDP is a wrapper over Xenomai's message pipe support, offering a socket-based interface to applications. Each XDDP port is mapped to a
given /dev/rtp device minor, but the communication endpoints between RT
and NRT are different internally.
[XDDP-port] &---& xnpipe #&port&
* input queue:
/dev/rtp -& xnpipe
* output queue: xnpipe -& /dev/rtp
/dev/rtp&port&
So, when NRT reads from /dev/rtp&port&, it does not actually listen to the same endpoint/queue than RT, because message pipes are
bi-directional. Likewise, NRT and RT never write to the same queue,
since the purpose of message pipes is to cross the RT/NRT domain boundary.&
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：142913次
积分：6078
积分：6078
排名：第1407名
原创：292篇
转载：614篇
译文：106篇
(45)(109)(51)(165)(92)(105)(220)(171)(34)(6)(19)(4)(1)(8)(6)(1)(1)}