Re: [Xenomai-core] [PATCH 0/4] Support for select-like services.
Gilles Chanteperdrix wrote:
>
> Hi,
>
> the following patchset adds core support to Xenomai for select-like
> services,
The attached patch is a quick and dirty patch of RTnet to allow using
rtnet sockets of all types with the new select service.
--
Gilles Chanteperdrix.
Index: stack/ipv4/af_inet.c
===
--- stack/ipv4/af_inet.c(révision 6193)
+++ stack/ipv4/af_inet.c(copie de travail)
@@ -259,8 +259,6 @@ static void rt_ip_ifdown(struct rtnet_de
rt_ip_route_del_all(rtdev);
}
-
-
static struct rtdev_event_hook rtdev_hook = {
register_device:NULL,
unregister_device: NULL,
@@ -294,6 +292,7 @@ static struct rtdm_device ipv4_device =
ioctl_nrt: rt_udp_ioctl,
recvmsg_rt: rt_udp_recvmsg,
sendmsg_rt: rt_udp_sendmsg,
+ select_bind:rt_socket_select_bind,
#ifdef CONFIG_RTNET_RTDM_SELECT
poll_rt:rt_udp_poll,
/* there should be only the function poll() */
Index: stack/include/rtnet_socket.h
===
--- stack/include/rtnet_socket.h(révision 6193)
+++ stack/include/rtnet_socket.h(copie de travail)
@@ -51,7 +51,8 @@ struct rtsocket {
unsigned intpriority;
nanosecs_rel_t timeout;/* receive timeout, 0 for infinite */
-rtdm_sem_t pending_sem;
+rtdm_select_sem_t pending_sem;
+struct xnselect write_select;
#ifdef CONFIG_RTNET_RTDM_SELECT
wait_queue_primitive_t *wakeup_select; /* for selecting calls - this
SHOULD be the head of a wait
@@ -96,6 +97,10 @@ static inline struct rtdm_dev_context *r
atomic_dec(&(rt_socket_context(sock)->close_lock_count))
extern int rt_socket_init(struct rtdm_dev_context *context);
+extern int rt_socket_select_bind(struct rtdm_dev_context *context,
+struct xnselector *selector,
+unsigned type,
+unsigned index);
extern int rt_socket_cleanup(struct rtdm_dev_context *context);
extern int rt_socket_common_ioctl(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info,
Index: stack/packet/af_packet.c
===
--- stack/packet/af_packet.c(révision 6193)
+++ stack/packet/af_packet.c(copie de travail)
@@ -467,7 +467,8 @@ static struct rtdm_device packet_proto
ioctl_rt: rt_packet_ioctl,
ioctl_nrt: rt_packet_ioctl,
recvmsg_rt: rt_packet_recvmsg,
-sendmsg_rt: rt_packet_sendmsg
+sendmsg_rt: rt_packet_sendmsg,
+ select_bind:rt_socket_select_bind,
},
device_class: RTDM_CLASS_NETWORK,
Index: stack/socket.c
===
--- stack/socket.c (révision 6193)
+++ stack/socket.c (copie de travail)
@@ -68,6 +68,7 @@ int rt_socket_init(struct rtdm_dev_conte
rtdm_lock_init(&sock->param_lock);
rtdm_sem_init(&sock->pending_sem, 0);
+xnselect_init(&sock->write_select);
if (test_bit(RTDM_CREATED_IN_NRT, &sockctx->context_flags))
pool_size = rtskb_pool_init(&sock->skb_pool, socket_rtskbs);
@@ -87,7 +88,44 @@ int rt_socket_init(struct rtdm_dev_conte
return 0;
}
+int rt_socket_select_bind(struct rtdm_dev_context *context,
+ struct xnselector *selector,
+ unsigned type,
+ unsigned index)
+{
+struct rtsocket *sock = (struct rtsocket *)&context->dev_private;
+
+switch(type) {
+case XNSELECT_READ:
+ return rtdm_select_sem_bind(&sock->pending_sem, selector, type, index);
+
+case XNSELECT_WRITE: {
+ struct xnselect_binding *binding;
+ int err;
+ spl_t s;
+
+ binding = xnmalloc(sizeof(*binding));
+ if (!binding)
+ return -ENOMEM;
+
+ xnlock_get_irqsave(&nklock, s);
+ /* Writing to a socket is always possible, so the state is 1, forever.
*/
+ err = xnselect_bind(&sock->write_select,
+ binding, selector, type, index, 1);
+ xnlock_put_irqrestore(&nklock, s);
+
+ if (err)
+ xnfree(binding);
+ return err;
+}
+case XNSELECT_EXCEPT:
+ return -EBADF;
+}
+
+return -EINVAL;
+}
+EXPORT_SYMBOL(rt_socket_select_bind);
/***
* rt_socket_cleanup - releases resources allocated for the socket
@@ -100,6 +138,7 @@ int rt_socket_cleanup(struct rtdm_dev_co
rtdm_sem_destroy(&sock->pending_sem);
+xnselect_destroy(&sock->write_select);
rtdm_lock_get_irqsave(&sock->param_lock, context);
___
Xenomai-core mailing list
Xeno
[Xenomai-core] [PATCH 4/4] posix skin user-space support for select
This one just adds the boiler-plate code to the user-space posix skin
for supporting select.
---
include/posix/sys/select.h | 23 +++
src/skins/posix/Makefile.am|1 +
src/skins/posix/posix.wrappers |1 +
src/skins/posix/select.c | 26 ++
src/skins/posix/wrappers.c |9 +
5 files changed, 60 insertions(+)
--- include/posix/sys/select.h (revision 0)
+++ include/posix/sys/select.h (revision 0)
@@ -0,0 +1,23 @@
+#ifndef _XENO_POSIX_SELECT_H
+#define _XENO_POSIX_SELECT_H
+
+#if !(defined(__KERNEL__) || defined(__XENO_SIM__))
+
+#include_next
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+extern int __real_select (int __nfds, fd_set *__restrict __readfds,
+ fd_set *__restrict __writefds,
+ fd_set *__restrict __exceptfds,
+ struct timeval *__restrict __timeout);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* !(__KERNEL__ || __XENO_SIM__) */
+
+#endif /* _XENO_POSIX_SELECT_H */
--- src/skins/posix/wrappers.c (revision 3441)
+++ src/skins/posix/wrappers.c (working copy)
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/* sched */
int __real_pthread_setschedparam(pthread_t thread,
@@ -235,3 +236,11 @@ int __real_munmap(void *addr, size_t len
{
return munmap(addr, len);
}
+
+int __real_select (int __nfds, fd_set *__restrict __readfds,
+ fd_set *__restrict __writefds,
+ fd_set *__restrict __exceptfds,
+ struct timeval *__restrict __timeout)
+{
+ return select(__nfds, __readfds, __writefds, __exceptfds, __timeout);
+}
--- src/skins/posix/select.c(revision 0)
+++ src/skins/posix/select.c(revision 0)
@@ -0,0 +1,26 @@
+#include
+#include
+#include
+
+extern int __pse51_muxid;
+
+int __wrap_select (int __nfds, fd_set *__restrict __readfds,
+ fd_set *__restrict __writefds,
+ fd_set *__restrict __exceptfds,
+ struct timeval *__restrict __timeout)
+{
+ int err;
+
+ err = XENOMAI_SKINCALL5(__pse51_muxid, __pse51_select, __nfds,
+ __readfds, __writefds, __exceptfds, __timeout);
+
+ if (err == -EBADF || err == -EPERM)
+ return __real_select(__nfds, __readfds,
+__writefds, __exceptfds, __timeout);
+
+ if (err > 0)
+ return err;
+
+ errno = -err;
+ return -1;
+}
--- src/skins/posix/posix.wrappers (revision 3441)
+++ src/skins/posix/posix.wrappers (working copy)
@@ -87,3 +87,4 @@
--wrap shm_unlink
--wrap mmap
--wrap munmap
+--wrap select
--- src/skins/posix/Makefile.am (revision 3441)
+++ src/skins/posix/Makefile.am (working copy)
@@ -15,6 +15,7 @@ libpthread_rt_la_SOURCES = \
mutex.c \
shm.c \
interrupt.c \
+ select.c \
rtdm.c \
wrappers.c
--
Gilles Chanteperdrix.___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 3/4] posix skin kernel-space support for select
This patch implements the select service for posix based user-space
applications.
It adds a pointer to a struct xnselector to each posix skin thread
control block, a struct xnselector gets allocated the first time a
thread calls select. When a descriptor gets passed for the first time to
xnselect, it returns -ECHRNG, which will cause select to create bindings
with the new file descriptors. When new descriptors are passed one by
one or select is always called with the same descriptors, which is
typical of applications using select, the call to select is
deterministic, it is O(1) if we count fd_set copy operations as
bounded.
The support for using message queue descriptors with select is also added.
---
include/posix/syscall.h |1
ksrc/skins/posix/internal.h |4 +
ksrc/skins/posix/mq.c | 78 +++-
ksrc/skins/posix/syscall.c | 120
ksrc/skins/posix/thread.c |5 +
ksrc/skins/posix/thread.h |4 +
6 files changed, 209 insertions(+), 3 deletions(-)
--- include/posix/syscall.h (revision 3441)
+++ include/posix/syscall.h (working copy)
@@ -100,6 +100,7 @@
#define __pse51_condattr_setpshared 74
#define __pse51_thread_getschedparam 75
#define __pse51_thread_kill 76
+#define __pse51_select77
#ifdef __KERNEL__
--- ksrc/skins/posix/syscall.c (revision 3441)
+++ ksrc/skins/posix/syscall.c (working copy)
@@ -34,6 +34,9 @@
#include
#include
#include
+#ifdef CONFIG_XENO_SKIN_RTDM
+#include
+#endif /* CONFIG_XENO_SKIN_RTDM */
int pse51_muxid;
@@ -1887,6 +1890,122 @@ static int __timer_getoverrun(struct pt_
return rc >= 0 ? rc : -thread_get_errno();
}
+static int select_bind(struct xnselector *selector, unsigned type, int fd)
+{
+ pse51_assoc_t *assoc;
+#ifdef CONFIG_XENO_SKIN_RTDM
+ const int rtdm_fd_start = FD_SETSIZE - RTDM_FD_MAX;
+
+ if (fd >= rtdm_fd_start)
+ return __rt_dev_select_bind(fd - rtdm_fd_start,
+ selector, type, fd);
+#endif /* CONFIG_XENO_SKIN_RTDM */
+
+ assoc = pse51_assoc_lookup(&pse51_queues()->uqds, fd);
+ if (!assoc)
+ return -EBADF;
+
+ return pse51_mq_select_bind(assoc2ufd(assoc)->kfd, selector, type, fd);
+}
+
+/* int select(int, fd_set *, fd_set *, fd_set *, struct timeval *) */
+static int __select(struct pt_regs *regs)
+{
+ fd_set in_fds[XNSELECT_MAX_TYPES], out_fds[XNSELECT_MAX_TYPES];
+ struct xnselector *selector;
+ struct timeval tv;
+ xnticks_t timeout;
+ pthread_t thread;
+ int err, nfds;
+
+ thread = pse51_current_thread();
+ if (!thread)
+ return -EPERM;
+
+ if (__xn_reg_arg5(regs)) {
+ if (__xn_copy_from_user(&tv,
+ (void __user *)__xn_reg_arg5(regs),
+ sizeof(tv)))
+ return -EFAULT;
+ if (tv.tv_usec > 100)
+ return -EINVAL;
+
+ timeout = clock_get_ticks(CLOCK_REALTIME)
+ + xntbase_ns2ticks(pse51_tbase,
+ (tv.tv_usec * 1000
+ + tv.tv_sec * 10ULL));
+ } else
+ timeout = XN_INFINITE;
+
+ nfds = __xn_reg_arg1(regs);
+
+ selector = thread->selector;
+ if (!selector) {
+ if (!(selector = xnmalloc(sizeof(*thread->selector
+ return -ENOMEM;
+ xnselector_init(selector);
+ thread->selector = selector;
+ }
+
+ if (__xn_reg_arg2(regs)) {
+ if (__xn_copy_from_user(&in_fds[XNSELECT_READ],
+ (void __user *) __xn_reg_arg2(regs),
+ __FDELT(nfds + __NFDBITS - 1) *
sizeof(long)))
+ return -EFAULT;
+ } else
+ __FD_ZERO(&in_fds[XNSELECT_READ]);
+
+ if (__xn_reg_arg3(regs)) {
+ if (__xn_copy_from_user(&in_fds[XNSELECT_WRITE],
+ (void __user *) __xn_reg_arg3(regs),
+ __FDELT(nfds + __NFDBITS - 1) *
sizeof(long)))
+ return -EFAULT;
+ } else
+ __FD_ZERO(&in_fds[XNSELECT_WRITE]);
+
+ if (__xn_reg_arg4(regs)) {
+ if (__xn_copy_from_user(&in_fds[XNSELECT_EXCEPT],
+ (void __user *) __xn_reg_arg4(regs),
+ __FDELT(nfds + __NFDBITS - 1) *
sizeof(long)))
+ return -EFAULT;
+ } else
+ __FD_ZERO(&in_fds[XNSELECT_EXCEPT]);
+
+ do {
+ err = xnselect(selector, out_fds, in_fds, nfds, timeout);
+
+ if (err == -ECHRNG) {
+
[Xenomai-core] [PATCH 2/4] modification of rtdm events and semaphores
This patch is IMO the most questionable of the whole set. It creates two
new RTDM objects, the selectable events and selectable semaphores, that
may be used for RTDM file descriptors to support select. It also adds
two services rtdm_select_event_bind, and rtdm_select_sem_bind, which
will allow to bind these objects with a struct xnselector.
What make it questionable is that it does this without adding new
services for the two new types, but rather uses the
__builtin_compatible_p() trick to allow using rtdm_event_* and
rtdm_sem_* services with the two new types.
The patch also adds a new method to the RTDM device ops, which will be
called (for instance by the posix skin), in order to bind an RTDM device
with a struct xnselector.
---
include/rtdm/rtdm.h|4
include/rtdm/rtdm_driver.h | 148 +-
ksrc/skins/rtdm/core.c | 26 ++
ksrc/skins/rtdm/device.c | 10 +
ksrc/skins/rtdm/drvlib.c | 446 ++---
5 files changed, 512 insertions(+), 122 deletions(-)
--- include/rtdm/rtdm_driver.h (revision 3441)
+++ include/rtdm/rtdm_driver.h (working copy)
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
/* debug support */
@@ -262,6 +263,11 @@ typedef ssize_t (*rtdm_sendmsg_handler_t
typedef int (*rtdm_rt_handler_t)(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info, void *arg);
+typedef int (*rtdm_select_bind_handler_t)(struct rtdm_dev_context *context,
+ struct xnselector *selector,
+ unsigned type,
+ unsigned index);
+
/**
* Device operations
*/
@@ -304,6 +310,8 @@ struct rtdm_operations {
/** Transmit message handler for non-real-time context (optional) */
rtdm_sendmsg_handler_t sendmsg_nrt;
/** @} Message-Oriented Device Operations */
+
+ rtdm_select_bind_handler_t select_bind;
};
struct rtdm_devctx_reserved {
@@ -1004,30 +1012,92 @@ typedef struct {
xnsynch_t synch_base;
} rtdm_event_t;
-#define RTDM_EVENT_PENDING XNSYNCH_SPARE1
+typedef struct {
+ rtdm_event_t event;
+ struct xnselect select_block;
+} rtdm_select_event_t;
-void rtdm_event_init(rtdm_event_t *event, unsigned long pending);
-int rtdm_event_wait(rtdm_event_t *event);
-int rtdm_event_timedwait(rtdm_event_t *event, nanosecs_rel_t timeout,
-rtdm_toseq_t *timeout_seq);
-void rtdm_event_signal(rtdm_event_t *event);
+#define RTDM_EVENT_PENDING XNSYNCH_SPARE1
-void rtdm_event_clear(rtdm_event_t *event);
+#ifndef TYPE_EQUAL
+#define TYPE_EQUAL(object, type) \
+__builtin_types_compatible_p(typeof(object), type *)
+#endif /* !TYPE_EQUAL */
+
+#define PICK_VOIDEVENTOP(op, object, args...) \
+do { \
+ if (TYPE_EQUAL((object), rtdm_event_t)) \
+ _rtdm_event_##op((rtdm_event_t *)(object), ##args); \
+ else if (TYPE_EQUAL((object), rtdm_select_event_t)) \
+ _rtdm_select_event_##op((rtdm_select_event_t *)(object), ##args); \
+} while (0)
+
+#define PICK_INTEVENTOP(op, object, args...) \
+({ \
+ int err = -ENOSYS; \
+ if (TYPE_EQUAL((object), rtdm_event_t)) \
+ err = _rtdm_event_##op((rtdm_event_t *)(object), ##args); \
+ else if (TYPE_EQUAL((object), rtdm_select_event_t)) \
+ err = _rtdm_select_event_##op((rtdm_select_event_t *)(object),
##args); \
+ err;\
+})
#ifndef DOXYGEN_CPP /* Avoid static inline tags for RTDM in doxygen */
+void _rtdm_event_init(rtdm_event_t *event, unsigned long pending);
+void _rtdm_select_event_init(rtdm_select_event_t *event, unsigned long
pending);
+#define rtdm_event_init(event, pending) PICK_VOIDEVENTOP(init, event, pending)
+
+int rtdm_select_event_bind(rtdm_select_event_t *event,
+ struct xnselector *selector,
+ unsigned type,
+ unsigned bit_index);
+
+int _rtdm_event_wait(rtdm_event_t *event);
+int _rtdm_select_event_wait(rtdm_select_event_t *event);
+#define rtdm_event_wait(event) PICK_INTEVENTOP(wait, event)
+
+int _rtdm_event_timedwait(rtdm_event_t *event, nanosecs_rel_t timeout,
+ rtdm_toseq_t *timeout_seq);
+int _rtdm_select_event_timedwait(rtdm_select_event_t *event,
+nanosecs_rel_t timeout,
+rtdm_toseq_t *timeout_seq);
+#define rtdm_event_timedwait(event, timeout, timeout_seq) \
+ PICK_INTEVENTOP(timedwait, event, timeout, t
[Xenomai-core] [PATCH 1/4] nucleus core support for select-like services.
This patch adds the basic functionality to the nucleus for supporting
select-like services.
The various types required may not be named with different enough
names. The "struct xnselect" structure must be put somewhere in the
structure associated with a file descriptor, to allow this file
descriptor to be used with select. The struct "xnselector structure"
keeps all the data necessary for handling several calls to select with
the same file descriptors sets without having to walk the sets at each
call. Since a "struct xnselect" may be bound to several "struct
xnselector" and reciprocally, there is a third data structure, named
"struct xnselect_binding", dynamically allocated, which represents a
binding between two instances of the structures.
Re-reading this code, I notice that we could improve xnslect performance
by taking note that any of the three descriptors might be empty.
---
include/nucleus/select.h | 111
ksrc/nucleus/Makefile|4
ksrc/nucleus/select.c| 405 +++
3 files changed, 518 insertions(+), 2 deletions(-)
--- include/nucleus/select.h(revision 0)
+++ include/nucleus/select.h(revision 0)
@@ -0,0 +1,111 @@
+/*!\file select.h
+ * \brief file descriptors events multiplexing header.
+ * \author Gilles Chanteperdrix
+ *
+ * Copyright (C) 2008 Efixo <[EMAIL PROTECTED]>
+ *
+ * Xenomai is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; either version 2 of the License,
+ * or (at your option) any later version.
+ *
+ * Xenomai is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with Xenomai; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+ * 02111-1307, USA.
+ *
+ * \ingroup select
+ */
+
+#ifndef XNSELECT_H
+#define XNSELECT_H
+
+/*! \addtogroup select
+ [EMAIL PROTECTED]/
+
+#include
+
+#define XNSELECT_READ 0
+#define XNSELECT_WRITE 1
+#define XNSELECT_EXCEPT2
+#define XNSELECT_MAX_TYPES 3
+
+struct xnselector {
+xnsynch_t synchbase;
+ struct fds {
+ fd_set expected;
+ fd_set pending;
+ } fds [XNSELECT_MAX_TYPES];
+ xnqueue_t bindings; /* only used by xnselector_destroy */
+};
+
+struct xnselect {
+ xnqueue_t bindings;
+};
+
+struct xnselect_binding {
+ struct xnselector *selector;
+ struct xnselect *fd;
+ unsigned type;
+ unsigned bit_index;
+ xnholder_t link; /* link in selected fds list. */
+ xnholder_t slink; /* link in selector list */
+};
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+void xnselect_init(struct xnselect *select_block);
+
+int xnselect_bind(struct xnselect *select_block,
+ struct xnselect_binding *binding,
+ struct xnselector *selector,
+ unsigned type,
+ unsigned bit_index,
+ unsigned state);
+
+int __xnselect_signal(struct xnselect *select_block, unsigned state);
+
+/**
+ * Signal a file descriptor state change.
+ *
+ * @param select_block pointer to an @a xnselect structure representing the
file
+ * descriptor whose state changed;
+ * @param state new value of the state.
+ *
+ * @retval 1 if rescheduling is needed;
+ * @retval 0 otherwise.
+ */
+static inline int
+xnselect_signal(struct xnselect *select_block, unsigned state)
+{
+ if (!emptyq_p(&select_block->bindings))
+ return __xnselect_signal(select_block, state);
+ return 0;
+}
+
+void xnselect_destroy(struct xnselect *select_block);
+
+int xnselector_init(struct xnselector *selector);
+
+int xnselect(struct xnselector *selector,
+fd_set out_fds[XNSELECT_MAX_TYPES],
+fd_set in_fds[XNSELECT_MAX_TYPES],
+int nfds,
+xnticks_t timeout);
+
+void xnselector_destroy(struct xnselector *selector);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+/[EMAIL PROTECTED]/
+
+#endif /* XNSELECT_H */
--- ksrc/nucleus/select.c (revision 0)
+++ ksrc/nucleus/select.c (revision 0)
@@ -0,0 +1,405 @@
+/*!\file select.c
+ * \brief file descriptors events multiplexing.
+ * \author Gilles Chanteperdrix
+ *
+ * Copyright (C) 2008 Efixo <[EMAIL PROTECTED]>
+ *
+ * Xenomai is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; either version 2 of the License,
+ * or (at your option) any later version.
+ *
+ * Xenomai is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHAN
[Xenomai-core] [PATCH 0/4] Support for select-like services.
Hi, the following patchset adds core support to Xenomai for select-like services, modifies the rtdm skin to allow running easily these services for rtdm file descriptors and implement the select service for the posix skin. select is an important service on low-end platform where it allows more efficient implementation of network server than with a threaded approach. It was only compile-tested for now, and will be tested around next week, so is submitted here for review only. Regards. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Some beginner technical questions
Jan Kiszka wrote: > Remi Lefevre wrote: > > Hi, I try to really understand the Xenomai design & behavior and have > > a few technical questions for which I can't find exact answers on > > documentations or mailing list : > > > > - What is the overhead of the Adeos/I-Pipe layer on non RT Linux tasks > > (including linux kernel) ? > > This surely depends on interrupts number, but perhaps some results on > > a particular platform exist. > > It also depends on the architecture and CPU speed. I can't provide > up-to-date numbers, and the best for you is anyway to evaluate > specifically your desired platform. This could mean running typical > Linux benchmark (eg. lmbench) on kernels with and without I-pipe + > Xenomai. You are always welcome to publish results and discuss them with us. Some number were published a long time ago on the LKML comparing the overhead of adeos and preempt_rt. It starts at: http://groups.google.com/group/linux.kernel/msg/b59137a4da507a55?hl=en >From my experience on ARM based Intel IXP465 hardware, the overhead of Adeos is invisible when observing network throughput or CPU consumption induced by this network traffic. > > > > > - When using RTnet, I understand that non RT Linux tasks uses a > > virtual network device linked to the RTnet one, so what performance > > impact does this have on non RT network bandwidth ? > > That depends. First of all, you only have to use the the virtual NICs > when you have to share the RT Ethernet link with non-RT traffic. > Otherwise you could simply use standard networking without penalties. If > VNICs are to be used, the performance Linux sees heavily depends on the > RTmac discipline and its configuration (e.g. the TDMA slot layout). Feel > free to continue on this topic on the rtnet-user list. I have a particular experience with IXP465 on this topic, using the nomac policy. First RTnet vnic TX suffer from a performance problem which is due to the fact that sending a packet wakes up a real-time task to send the packet. Since the task is real-time, it wakes up immediately, so there is no way the packets may be batched, and for every packet sent, we pay the price of a context switch. Once this bottleneck removed and after a few other minor performance improvements, I could make some measurements: - on IXP465 running vanilla linux, NATing a 100 Mbits/sec traffic consumes 80% of CPU; - when running through RTnet vnics, it consumes 100% of CPU for a traffic around 95 Mbits/sec, so, it does not come for free, but remains acceptable. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Some beginner technical questions
Remi Lefevre wrote: > Hi, I try to really understand the Xenomai design & behavior and have > a few technical questions for which I can't find exact answers on > documentations or mailing list : > > - What is the overhead of the Adeos/I-Pipe layer on non RT Linux tasks > (including linux kernel) ? > This surely depends on interrupts number, but perhaps some results on > a particular platform exist. It also depends on the architecture and CPU speed. I can't provide up-to-date numbers, and the best for you is anyway to evaluate specifically your desired platform. This could mean running typical Linux benchmark (eg. lmbench) on kernels with and without I-pipe + Xenomai. You are always welcome to publish results and discuss them with us. > > - When using RTnet, I understand that non RT Linux tasks uses a > virtual network device linked to the RTnet one, so what performance > impact does this have on non RT network bandwidth ? That depends. First of all, you only have to use the the virtual NICs when you have to share the RT Ethernet link with non-RT traffic. Otherwise you could simply use standard networking without penalties. If VNICs are to be used, the performance Linux sees heavily depends on the RTmac discipline and its configuration (e.g. the TDMA slot layout). Feel free to continue on this topic on the rtnet-user list. > > I saw on some introduction slides that an arinc 653 skin would be possible. > Emulating the arinc 653 is certainly possible, but if a real arinc 653 > system is considered, this raises a few technical issues. > - Is the nucleus memory space protected from the Linux kernel (at > least in primary mode) ? If not, would this be possible ? Nucleus, skins, and Linux kernel share the same memory space and run at the same privilege level. This enables very advanced Linux integration of RT threads and significantly reduces the performance impact on Linux (and/or the need to add emulation/paravirtualisation code). Before thinking about any design to add such memory protection domains for Linux and I-pipe/Xenomai, it should be clarified what level of protection is required. Full protection means not just establishing separate memory domain, but also pushing Linux out of the supervisor mode. And that means a lot of work - to provide all the trusted hardware drivers in the context of some hypervisor, because Linux is untrusted and unprivileged then. Some less drastic approach might be to isolate the Nucleus from Linux, but to trust Linux (and it's drivers) to a) not install invalid page tables and b) not program DMA-capable hardware with invalid addresses. But I can't comment on if this approach is acceptable for whatsoever "critical" ARINC 653 application (and its potential certification). > - It seems from what I understand that nucleus implements threads, but > not processes (like others RTOS), does this mean that they all share > the same memory space ? If you write your applications for the Linux kernel space (not recommended!), then they share the memory space with everything else in the kernel. But when you write user space applications, Xenomai reuses the process abstraction and protection Linux already provides. So, process are protected from each other, even if they include Xenomai RT threads. > - Can the nucleus kernel still run if the Linux kernel crashes (which > happens in ring 1 mode on x86 if I'm correct) ? [Linux runs at ring 0 - don't trust old written concepts of Adeos.] There are certain fault scenarios of the Linux kernel which will not impact the nucleus - but that should be carefully analyzed for the particular system (as you do with _every_ critical system anyway). > - Or more generally, what Linux kernel services are used by nucleus > (it seems at least the memory allocation ones) ? What is a "Linux kernel service" for you? Some potentially blocking or failing kernel subsystem or also some inline functions from Linux headers etc.? Bugs aside, the former is definitely not the case while the later is unavoidable for certain shared services (which are generally checked on kernel updates and/or with the help of kernel instrumentations). > - This is linked to the previous questions, but if we wanted to remove > everything from the Linux kernel that is not used by Xenomai, what > would be necessary to keep ? For what level of Xenomai services? Something like a stand-alone nucleus + in-kernel applications? In any case, Xenomai is built on the environment that Linux provides, with all the platform and peripheral hardware initialized and managed later on. So it heavily depends on what you want for such a scenario, and then you will have to provide it on your own (look at what Xen does these days: reimplementing wide parts of the tricky board setup that Linux normally provides - with all its quirks). > - At last, is there a way to guaranty a worst case latency on Xenomai > (even a high one) supposing we know every hardware behavior (hum...) ? The Xenomai desig
