Commit d0d67d97 authored by Philippe Gerum's avatar Philippe Gerum
Browse files

doc: prebuild

parent f9ed3db4
......@@ -1006,10 +1006,10 @@ of all timers from the registered Xenomai clocks.
</dd>
</dl></div>
<div class="paragraph"><p>There is no kernel-based time base management anymore with Xenomai
3.0-rc7. Functionally speaking, only the former <em>master</em> time base
3.0. Functionally speaking, only the former <em>master</em> time base
remains, periodic timing is now controlled locally from the Xenomai
libraries in user-space.</p></div>
<div class="paragraph"><p>Xenomai 3.0-rc7 defines a built-in clock named <em>coreclk</em>, which has
<div class="paragraph"><p>Xenomai 3.0 defines a built-in clock named <em>coreclk</em>, which has
the same properties than the former <em>master</em> time base available with
Xenomai 2.x (i.e. tickless with nanosecond resolution).</p></div>
<div class="paragraph"><p>The settings of existing clocks can be read from entries under the new
......@@ -1722,23 +1722,25 @@ upon notification, which therefore applies to RTDM tasks as well.</p></div>
<div class="ulist"><ul>
<li>
<p>
<code>rtdm_task_set_period()</code> does not suspend the target task until the
first release point is reached. If a start date is specified, then
<code>rtdm_task_wait_period()</code> will apply the initial delay.
<code>rtdm_task_set_period()</code> now accepts a start date for the periodic
timeline. Zero can be passed to emulate the previous call form,
setting the first release point when the first period after the
current date elapses.
</p>
</li>
<li>
<p>
<code>rtdm_task_wait_period()</code> now copies back the count of overruns into
a user-provided variable if -ETIMEDOUT is returned. NULL can be passed
to emulate the previous call form, discarding this information.
</p>
</li>
<li>
<p>
Both <code>rtdm_task_set_period()</code> and <code>rtdm_task_wait_period()</code> may be
invoked over a Cobalt thread context.
</p>
</li>
</ul></div>
<div class="sidebarblock">
<div class="content">
<div class="title">Rationale</div>
<div class="paragraph"><p>A periodic RTDM task has to call <code>rtdm_task_wait_period()</code> from within
its work loop for sleeping until the next release point is
reached. Since waiting for the initial and subsequent release points
will most often happen at the same code location in the driver, the
semantics of <code>rtdm_task_set_period()</code> can be simplified so that only
<code>rtdm_task_wait_period()</code> may block the caller.</p></div>
</div></div>
<div class="ulist"><ul>
<li>
<p>
RTDM_EXECUTE_ATOMICALLY() is deprecated and will be phased out in
......@@ -2332,9 +2334,15 @@ kernel Cobalt environment.</td>
<div class="ulist"><ul>
<li>
<p>
Cobalt implements the following POSIX.1-2001 services not present in
Xenomai 2.x: <code>sched_setscheduler(2)</code>, <code>sched_getscheduler(2)</code>.
</p>
</li>
<li>
<p>
The <code>SCHED_FIFO</code>, <code>SCHED_RR</code>, <code>SCHED_SPORADIC</code> and <code>SCHED_TP</code>
classes now support up to 256 priority levels, instead of 99 as
previously with Xenomai 2.x. However, <code>sched_get_priority_max()</code>
previously with Xenomai 2.x. However, <code>sched_get_priority_max(2)</code>
still returns 99. Only the Cobalt extended call forms
(e.g. <code>pthread_attr_setschedparam_ex()</code>, <code>pthread_create_ex()</code>)
recognize these additional levels.
......@@ -2342,14 +2350,14 @@ The <code>SCHED_FIFO</code>, <code>SCHED_RR</code>, <code>SCHED_SPORADIC</code>
</li>
<li>
<p>
<code>sched_get_priority_min_ex()</code> and <code>sched_get_priority_max_ex()</code>
should be used for querying the static priority range of Cobalt
policies.
The new <code>sched_get_priority_min_ex()</code> and
<code>sched_get_priority_max_ex()</code> services should be used for querying
the static priority range of Cobalt policies.
</p>
</li>
<li>
<p>
<code>pthread_setschedparam()</code> may cause a secondary mode switch for the
<code>pthread_setschedparam(3)</code> may cause a secondary mode switch for the
caller, but will not cause any mode switch for the target thread
unlike with Xenomai 2.x.
</p>
......@@ -2357,11 +2365,11 @@ The <code>SCHED_FIFO</code>, <code>SCHED_RR</code>, <code>SCHED_SPORADIC</code>
Xenomai scheduler in sync, with respect to thread priorities, since
the former maintains a process-local priority cache for the threads
it knows about. Therefore, an explicit call to the the regular
<code>pthread_setschedparam()</code> shall be issued upon each priority change
<code>pthread_setschedparam(3)</code> shall be issued upon each priority change
Xenomai-wise, for maintaining consistency.</p></div>
<div class="paragraph"><p>In the Xenomai 2.x implementation, the thread being set a new
priority would receive a SIGSHADOW signal, triggering a call to
<code>pthread_setschedparam()</code> immediately.</p></div>
<code>pthread_setschedparam(3)</code> immediately.</p></div>
</li>
</ul></div>
<div class="sidebarblock">
......@@ -2371,10 +2379,10 @@ priority would receive a SIGSHADOW signal, triggering a call to
only be held in primary mode, in which case switching to secondary
mode for applying the priority change at any random location over a
signal handler may create a pathological issue. In addition,
<code>pthread_setschedparam()</code> is not async-safe, which makes the former
<code>pthread_setschedparam(3)</code> is not async-safe, which makes the former
method fragile.</p></div>
</div></div>
<div class="paragraph"><p>Conversely, a thread which calls <code>pthread_setschedparam()</code> does know
<div class="paragraph"><p>Conversely, a thread which calls <code>pthread_setschedparam(3)</code> does know
unambiguously whether the current calling context is safe for the
incurred migration.</p></div>
<div class="ulist"><ul>
......@@ -2397,7 +2405,7 @@ extent of the regular Linux SCHED_FIFO/RR priority range.</p></div>
class at priority level 20 in the Cobalt core, may be scheduled with
policy SCHED_FIFO/RR at priority 20, by the Linux kernel. The code
fragment below would set the scheduling parameters accordingly,
assuming the Cobalt version of <code>pthread_setschedparam()</code> is invoked:</p></div>
assuming the Cobalt version of <code>pthread_setschedparam(3)</code> is invoked:</p></div>
</li>
</ul></div>
<div class="listingblock">
......@@ -2435,7 +2443,7 @@ to each group, in accordance with its share.</p></div>
</li>
<li>
<p>
When called from primary mode, sched_yield() now delays the caller
When called from primary mode, sched_yield(2) now delays the caller
for a short while <strong>only in case</strong> no context switch happened as a
result of the manual round-robin. The delay ends next time the
regular Linux kernel switches tasks, or a kernel (virtual) tick has
......@@ -2449,7 +2457,7 @@ delayed for a while.</p></div>
<div class="sidebarblock">
<div class="content">
<div class="title">Rationale</div>
<div class="paragraph"><p>In most case, it is unwanted that sched_yield() does not cause any
<div class="paragraph"><p>In most case, it is unwanted that sched_yield(2) does not cause any
context switch, since this service is commonly used for implementing a
poor man&#8217;s cooperative scheduling. A typical use case involves a
Xenomai thread running in primary mode which needs to yield the CPU to
......@@ -2466,9 +2474,8 @@ out the delayed Xenomai thread indefinitely.</p></div>
<div class="ulist"><ul>
<li>
<p>
The default POSIX thread stack size was raised to
<code>PTHREAD_STACK_MIN * 4</code>. The minimum stack size enforced by the
<code>libcobalt</code> library is <code>PTHREAD_STACK_MIN + getpagesize()</code>.
The minimum and default stack size is set to <code>max(64k,
PTHREAD_STACK_MIN)</code>.
</p>
</li>
<li>
......@@ -2507,8 +2514,8 @@ condition variable).</td>
<div class="ulist"><ul>
<li>
<p>
With Cobalt, sem_wait(), sem_trywait(), sem_timedwait(), and
sem_post() have gained fast acquisition/release operations not
With Cobalt, sem_wait(3), sem_trywait(3), sem_timedwait(3), and
sem_post(3) have gained fast acquisition/release operations not
requiring any system call, unless a contention exists on the
resource. As a consequence, those services may not systematically
switch callers executing in relaxed mode to real-time mode, unlike
......@@ -2522,8 +2529,8 @@ With Cobalt, sem_wait(), sem_trywait(), sem_timedwait(), and
<div class="ulist"><ul>
<li>
<p>
In a <code>fork()</code> &#8594; <code>exec()</code> sequence, all Cobalt API objects created
by the child process before it calls <code>exec()</code> are automatically
In a <code>fork(2)</code> &#8594; <code>exec(2)</code> sequence, all Cobalt API objects created
by the child process before it calls <code>exec(2)</code> are automatically
flushed by the Xenomai core.
</p>
</li>
......@@ -2538,9 +2545,9 @@ Support for Xenomai real-time signals is available.
</p>
</li>
</ul></div>
<div class="paragraph"><p>Cobalt replacements for <code>sigwait()</code>, <code>sigwaitinfo()</code>,
<code>sigtimedwait()</code>, <code>sigqueue()</code> and <code>kill()</code> are
available. <code>pthread_kill()</code> was changed to send thread-directed
<div class="paragraph"><p>Cobalt replacements for <code>sigwait(3)</code>, <code>sigwaitinfo(2)</code>,
<code>sigtimedwait(2)</code>, <code>sigqueue(3)</code> and <code>kill(2)</code> are
available. <code>pthread_kill(3)</code> was changed to send thread-directed
Xenomai signals (instead of regular Linux signals).</p></div>
<div class="paragraph"><p>Cobalt-based signals are stricly real-time. Both the sender and
receiver sides work exclusively from the primary domain. However, only
......@@ -2557,32 +2564,32 @@ any signal.</p></div>
<div class="ulist"><ul>
<li>
<p>
<code>kill()</code> supports group signaling.
Cobalt&#8217;s <code>kill(2)</code> implementation supports group signaling.
</p>
</li>
</ul></div>
<div class="paragraph"><p>Cobalt&#8217;s implementation of kill() behaves identically to the regular
<div class="paragraph"><p>Cobalt&#8217;s implementation of kill(2) behaves identically to the regular
system call for non thread-directed signals (i.e. pid &#8656; 0). In this
case, the caller switches to secondary mode.</p></div>
<div class="paragraph"><p>Otherwise, Cobalt first attempts to deliver a thread-directed signal
to the thread whose kernel TID matches the given process id. If this
thread is not waiting for signals at the time of the call, kill() then
thread is not waiting for signals at the time of the call, kill(2) then
attempts to deliver the signal to a thread from the same process,
which currently waits for a signal.</p></div>
<div class="ulist"><ul>
<li>
<p>
<code>pthread_kill()</code> is a conforming call.
<code>pthread_kill(3)</code> is a conforming call.
</p>
</li>
</ul></div>
<div class="paragraph"><p>When Cobalt&#8217;s replacement for <code>pthread_kill()</code> is invoked, a
<div class="paragraph"><p>When Cobalt&#8217;s replacement for <code>pthread_kill(3)</code> is invoked, a
Xenomai-enabled caller is automatically switched to primary mode on
its way to sending the signal, under the control of the real-time
co-kernel. Otherwise, the caller keeps running under the control of
the regular Linux kernel.</p></div>
<div class="paragraph"><p>This behavior also applies to the new Cobalt-based replacement for the
<code>kill()</code> system call.</p></div>
<code>kill(2)</code> system call.</p></div>
</div>
<div class="sect2">
<h3 id="_timers">8.7. Timers</h3>
......@@ -2598,13 +2605,13 @@ POSIX timers are no longer dropped when the creator thread
If the thread signaled by a POSIX timer exits, the timer is
automatically stopped at the first subsequent timeout which fails
sending the notification. The timer lingers until it is deleted by a
call to <code>timer_delete()</code> or when the process exits, whichever comes
call to <code>timer_delete(2)</code> or when the process exits, whichever comes
first.
</p>
</li>
<li>
<p>
timer_settime() may be called from a regular thread (i.e. which is
timer_settime(2) may be called from a regular thread (i.e. which is
not Xenomai-enabled).
</p>
</li>
......@@ -2616,8 +2623,8 @@ EPERM is not returned anymore by POSIX timer calls. EINVAL is
</li>
<li>
<p>
Cobalt replacements for <code>timerfd_create()</code>, <code>timerfd_settime()</code> and
<code>timerfd_gettime()</code> have been introduced. The implementation delivers
Cobalt replacements for <code>timerfd_create(2)</code>, <code>timerfd_settime(2)</code> and
<code>timerfd_gettime(2)</code> have been introduced. The implementation delivers
I/O notifications to RTDM file descriptors upon Cobalt-originated
real-time signals.
</p>
......@@ -2635,15 +2642,15 @@ removed from the API.
<div class="paragraph"><p>With the introduction of services to support real-time signals, those
two non-portable calls have become redundant. Instead, Cobalt-based
applications should set up a periodic timer using the
<code>timer_create()</code>+<code>timer_settime()</code> call pair, then wait for release
points via <code>sigwaitinfo()</code>. Overruns can be detected by looking at the
<code>timer_create(2)</code>+<code>timer_settime(2)</code> call pair, then wait for release
points via <code>sigwaitinfo(2)</code>. Overruns can be detected by looking at the
siginfo.si_overrun field.</p></div>
<div class="paragraph"><p>Alternatively, applications may obtain a file descriptor referring to
a Cobalt timer via the <code>timerfd()</code> call, and <code>read()</code> from it to wait
a Cobalt timer via the <code>timerfd_create(2)</code> call, and <code>read(2)</code> from it to wait
for timeouts.</p></div>
<div class="paragraph"><p>In addition, applications may include a timer in a synchronous
multiplexing operation involving other event sources, by passing a
file descriptor returned by the <code>timerfd()</code> service to a <code>select()</code>
file descriptor returned by the <code>timerfd_create(2)</code> service to a <code>select(2)</code>
call.</p></div>
</div></div>
<div class="admonitionblock">
......@@ -2681,13 +2688,13 @@ is subject to change with ABI revisions.</td>
<div class="ulist"><ul>
<li>
<p>
<code>mq_open()</code> default attributes align on the regular kernel values,
<code>mq_open(3)</code> default attributes align on the regular kernel values,
i.e. 10 msg x 8192 bytes (instead of 128 x 128).
</p>
</li>
<li>
<p>
<code>mq_send()</code> now enforces a maximum priority value for messages
<code>mq_send(3)</code> now enforces a maximum priority value for messages
(32768).
</p>
</li>
......@@ -2771,11 +2778,21 @@ receipts, as explained <a href="#userirqtip">here</a>.</td>
<div class="ulist"><ul>
<li>
<p>
The RT_IOREGION API is gone. I/O memory resources should
be controlled from a RTDM driver instead.
The RT_IOREGION API is gone. I/O memory resources should be
controlled from a RTDM driver instead.
</p>
</li>
</ul></div>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<img src="../asciidoc-icons/tip.png" alt="Tip" />
</td>
<td class="content"><a href="#userirqtip">UDD</a> provides a simple way to implement mini-drivers
exposing any kind of memory regions to applications in user-space, via
Cobalt&#8217;s mmap(2) call.</td>
</tr></table>
</div>
</div>
<div class="sect2">
<h3 id="_timing_services">9.4. Timing services</h3>
......@@ -3453,7 +3470,7 @@ CC = $(shell $(CONFIG_CMD) --cc)</code></pre>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated 2015-08-15 16:32:54 CEST
Last updated 2015-10-07 11:08:43 CEST
</div>
</div>
</body>
......
......@@ -850,7 +850,7 @@ package is called <em>valgrind-devel</em> on Fedora.</td>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated 2015-08-15 16:32:54 CEST
Last updated 2015-10-07 11:08:43 CEST
</div>
</div>
</body>
......
......@@ -2023,7 +2023,7 @@ Xenomai 3.x, you should have a look at
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated 2015-08-15 16:32:54 CEST
Last updated 2015-10-07 11:08:43 CEST
</div>
</div>
</body>
......
......@@ -982,27 +982,35 @@ users to access Xenomai services, by following the instructions on
</div>
<div class="sect2">
<h3 id="_abi_mismatch">2.5. ABI mismatch</h3>
<div class="paragraph"><p>The ABI concerned by this message is the system call binary interface
between the Xenomai libraries and the real-time kernel services it
invokes (e.g. <code>libcobalt</code> and the Cobalt kernel with Xenomai
3.x). This ABI may evolve over time, only between major Xenomai
releases or testing candidate releases (i.e. -rc series) though. When
this happens, the ABI level required by the application linked against
Xenomai libraries may not match the ABI exposed by the Xenomai
co-kernel implementation on the target machine, which is the situation
this message reports.</p></div>
<div class="paragraph"><p>To fix this issue, just make sure to rebuild both the Xenomai kernel
support and the user-space binaries for your target system. If however
you did install the appropriate Xenomai binaries on your target
system, chances are that stale files from a previous Xenomai
installation still exist on your system, causing the mismatch.</p></div>
<div class="paragraph"><p>Each major Xenomai release (e.g. 2.1.x, 2.2.x &#8230; 2.6.x, 3.0.x &#8230;)
defines a kernel/user ABI, which remains stable across minor update
releases (e.g. 2.6.0 &#8594; 2.6.1). This guarantee makes partial updates
possible with production systems (i.e. kernel and/or user support).</p></div>
<div class="paragraph"><p>For instance, any application built over the Xenomai 2.6.0 libraries
can run over a Xenomai 2.6.3 kernel support, and conversely.</p></div>
<div class="paragraph"><p>However, it is not possible to mix kernel and user-space supports from
different major releases.</p></div>
defines such kernel/user ABI, which remains stable across minor update
releases (e.g. 2.6.0 &#8594; 2.6.4). This guarantee makes partial updates
possible with production systems (i.e. kernel and/or user support).
For instance, any application built over the Xenomai 2.6.0 binaries
can run over a Xenomai 2.6.4 kernel support, and conversely.</p></div>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<img src="../asciidoc-icons/tip.png" alt="Tip" />
</td>
<td class="content">A common source of error is running a kernel with support from the
Xenomai 2.6.x series, on a system with pre-installed Xenomai libraries
from the 2.5.x series, shipped with a Debian-based Linux distribution
(notably Ubuntu), which won&#8217;t work as the two series have different
ABIs. If however you did install the correct Xenomai user-space
support on your target system, chances are that stale files from a
previous Xenomai installation still exist on your system, causing the
mismatch.</td>
<td class="content">Debian-based distributions (notably Ubuntu) may ship with
pre-installed Xenomai libraries. Make sure that these files don&#8217;t get
in the way if you plan to install a more recent Xenomai kernel
support.</td>
</tr></table>
</div>
</div>
......@@ -1459,7 +1467,7 @@ allocation requests.</p></div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated 2015-08-15 16:32:54 CEST
Last updated 2015-10-07 11:08:43 CEST
</div>
</div>
</body>
......
......@@ -763,7 +763,7 @@ specific
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated 2015-08-15 16:32:54 CEST
Last updated 2015-10-07 11:08:43 CEST
</div>
</div>
</body>
......
......@@ -755,7 +755,7 @@ XENO-CONFIG(1) Manual Page
<div class="paragraph"><p><strong>xeno-config</strong> <strong>--info</strong></p></div>
<div class="paragraph"><p><strong>xeno-config</strong> <strong>--core</strong></p></div>
<div class="paragraph"><p><strong>xeno-config</strong> <strong>--version</strong></p></div>
<div class="paragraph"><p><strong>xeno-config</strong> [<strong>--cc</strong>] [<strong>--ccld</strong>] [<strong>--arch</strong>] [<strong>--prefix</strong>] [<strong>--posix|alchemy|rtdm|psos|vxworks|smokey</strong>] [<strong>--compat</strong>] [<strong>--auto-init</strong>|<strong>no-auto-init</strong>] [<strong>--cflags</strong>] [<strong>--kcflags</strong>] [<strong>--ldflags</strong>] [<strong>--library-dir</strong>|<strong>--libdir</strong>|<strong>--user-libdir</strong>]</p></div>
<div class="paragraph"><p><strong>xeno-config</strong> [<strong>--cc</strong>] [<strong>--ccld</strong>] [<strong>--arch</strong>] [<strong>--prefix</strong>] [<strong>--posix|alchemy|rtdm|psos|vxworks|smokey</strong>] [<strong>--compat</strong>] [<strong>--auto-init</strong>|<strong>no-auto-init</strong>] [<strong>--cflags</strong>] [<strong>--ldflags</strong>] [<strong>--library-dir</strong>|<strong>--libdir</strong>|<strong>--user-libdir</strong>]</p></div>
</div>
</div>
<div class="sect1">
......@@ -889,17 +889,6 @@ to compile applications based on the selected Xenomai API/skin.
</p>
</dd>
<dt class="hdlist1">
<strong>--kcflags</strong>
</dt>
<dd>
<p>
Output the C compiler command-line options (<em>CFLAGS</em>) which are
required to compile a kernel driver based on the RTDM
interface. <strong>--rtdm</strong> must appear on the command line before
<strong>--kcflags</strong>.
</p>
</dd>
<dt class="hdlist1">
<strong>--ldflags</strong>
</dt>
<dd>
......@@ -1037,7 +1026,7 @@ Error.
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated 2015-07-06 17:15:13 CEST
Last updated 2015-10-06 16:52:49 CEST
</div>
</div>
</body>
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......@@ -380,7 +380,7 @@ $(document).ready(function(){initNavTree('16550A__pci_8h_source.html','');});
<div class="line"><a name="l00284"></a><span class="lineno"> 284</span>&#160;<span class="preprocessor">#define rt_16550_pci_cleanup() do { } while (0)</span></div>
<div class="line"><a name="l00285"></a><span class="lineno"> 285</span>&#160;</div>
<div class="line"><a name="l00286"></a><span class="lineno"> 286</span>&#160;<span class="preprocessor">#endif </span><span class="comment">/* Linux &lt; 2.6.0 || !CONFIG_PCI || !(..._16550A_PCI */</span><span class="preprocessor"></span></div>
<div class="ttc" id="group__rtdm__irq_html_gab26458b2383dd59b4977cd77c948cdfc"><div class="ttname"><a href="group__rtdm__irq.html#gab26458b2383dd59b4977cd77c948cdfc">RTDM_IRQTYPE_SHARED</a></div><div class="ttdeci">#define RTDM_IRQTYPE_SHARED</div><div class="ttdoc">Enable IRQ-sharing with other real-time drivers. </div><div class="ttdef"><b>Definition:</b> driver.h:788</div></div>
<div class="ttc" id="group__rtdm__irq_html_gab26458b2383dd59b4977cd77c948cdfc"><div class="ttname"><a href="group__rtdm__irq.html#gab26458b2383dd59b4977cd77c948cdfc">RTDM_IRQTYPE_SHARED</a></div><div class="ttdeci">#define RTDM_IRQTYPE_SHARED</div><div class="ttdoc">Enable IRQ-sharing with other real-time drivers. </div><div class="ttdef"><b>Definition:</b> driver.h:792</div></div>
</div><!-- fragment --></div><!-- contents -->
</div><!-- doc-content -->
<!-- start footer part -->
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......
This diff is collapsed.
......@@ -15,6 +15,7 @@ var annotated =
[ "can_bittime_std", "structcan__bittime__std.html", "structcan__bittime__std" ],
[ "can_filter", "structcan__filter.html", "structcan__filter" ],
[ "can_frame", "structcan__frame.html", "structcan__frame" ],
[ "can_ifreq", "structcan__ifreq.html", null ],
[ "macb_dma_desc", "structmacb__dma__desc.html", "structmacb__dma__desc" ],
[ "macb_tx_skb", "structmacb__tx__skb.html", "structmacb__tx__skb" ],
[ "RT_ALARM_INFO", "structRT__ALARM__INFO.html", "structRT__ALARM__INFO" ],
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......
......@@ -34,7 +34,7 @@
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">Xenomai
&#160;<span id="projectnumber">3.0-rc7</span>
&#160;<span id="projectnumber">3.0</span>
</div>
</td>
</tr>
......@@ -88,9 +88,10 @@ $(document).ready(function(){initNavTree('api-tags.html','');});
<div class="title">API service tags </div> </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><p>The non-POSIX API services based on the Copperplate library may be restricted to particular calling contexts, or entail specific side-effects.</p>
<p>This information applies to the Alchemy API services, and to all RTOS emulators as well. To describe this information, each service documented by this section bears a set of tags when applicable.</p>
<div class="textblock"><p>All services from the Cobalt/POSIX library, or which belong to APIs based on the Copperplate library may be restricted to particular calling contexts, or entail specific side-effects.</p>
<p>Therefore, the information below applies to all application-oriented APIs available with Xenomai, such as the Cobalt/POSIX library, the Alchemy API, and to all RTOS emulators as well. To describe this information, each service documented by this section bears a set of tags when applicable.</p>
<p>The table below matches the tags used throughout the documentation with the description of their meaning for the caller.</p>
<dl class="section attention"><dt>Attention</dt><dd>By Xenomai thread, we mean any thread created by a Xenomai API service, including real-time Cobalt/POSIX threads in dual kernel mode. By regular POSIX thread, we mean any thread directly created by the standard <em>glibc-based</em> POSIX service over Mercury (i.e. NPTL/linuxthreads <a class="el" href="group__cobalt__api__thread.html#gae1a96424296ef872696c7fb90a8ae9aa" title="Create a new thread. ">pthread_create()</a>), excluding such threads which have been promoted to the real-time domain afterwards (aka "shadowed") over Cobalt.</dd></dl>
<dl class="section user"><dt></dt><dd><b>Context tags</b> <table class="doxtable">
<tr>
<th>Tag </th><th>Context on entry </th></tr>
......@@ -110,10 +111,9 @@ $(document).ready(function(){initNavTree('api-tags.html','');});
<td>unrestricted </td><td>May be called from any context previously described </td></tr>
</table>
</dd></dl>
<dl class="section note"><dt>Note</dt><dd>A Xenomai handler is most often used for callback-based timeout notifications. This context is <em>NOT</em> mapped to a regular Linux signal handler, it is actually underlaid by a special thread context, so that async-unsafe POSIX services may be invoked internally by the API implementation when running on behalf of such handler. Therefore, calling Xenomai API services from asynchronous regular signal handlers is fundamentally unsafe.</dd>
<dd>
A non-blocking call for an API service is defined by a special value passed as a timeout specification.</dd></dl>
<dl class="section user"><dt></dt><dd><b>Possible side-effects over the Cobalt core (i.e. dual kernel configuration)</b> <table class="doxtable">
<dl class="section note"><dt>Note</dt><dd>A Xenomai handler is used for callback-based notifications from Copperplate-based APIs, such as timeouts. This context is <em>NOT</em> mapped to a regular Linux signal handler, it is actually underlaid by a special thread context, so that async-unsafe POSIX services may be invoked internally by the API implementation when running on behalf of such handler. Therefore, calling Xenomai API services from asynchronous regular signal handlers is fundamentally unsafe.</dd></dl>
<dl class="section user"><dt></dt><dd><b>Possible side-effects when running the application over the Cobalt core (i.e. dual kernel configuration)</b></dd></dl>