Re: [Xenomai-core] [PATCH 0/5] Support for select v2.
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Hi, after some tests, bug fixes and optimizations, here comes a second version of the patch-set adding select support to xenomai posix skin. Puh, a lot of code, and my brain is still full of KGDB stuff I'm trying to polish for mainline since days. The approach looks consistent to me. I would just suggest to make the whole thing configurable, so that it doesn't add overhead to systems which do not use it. I am getting back to this select stuff. So I have a question, would you agree if the select support was made configurable, but if when this support was enabled, support for select was added to vanilla rtdm_event_t and rtdm_sem_t ? This would ease maintenance, since it would avoid a lot of code duplication, without adding to much overhead in my opinion (an empty list test when signaling the objects). Out of curiosity: Did you already have a chance to compare a multi-threaded demo application with one based on these new select services? I guess your current test cases are built on top of RTnet, aren't they? Would be nice, also for regression testing, to have some demo for /examples, e.g. exploiting the CAN stack (because it has virtual CAN, thus it is usable without hardware). Ok, I had a look at the CAN stack, if I understand correctly when receiving, the recv_sem defined in rcan_socket.h is used, and when sending, the tx_sem defined in rtcan_dev.h is used. Can you confirm this ? -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 0/5] Support for select v2.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Hi, after some tests, bug fixes and optimizations, here comes a second version of the patch-set adding select support to xenomai posix skin. Puh, a lot of code, and my brain is still full of KGDB stuff I'm trying to polish for mainline since days. The approach looks consistent to me. I would just suggest to make the whole thing configurable, so that it doesn't add overhead to systems which do not use it. I am getting back to this select stuff. So I have a question, would you agree if the select support was made configurable, but if when this support was enabled, support for select was added to vanilla rtdm_event_t and rtdm_sem_t ? This would ease maintenance, since it would avoid a lot of code duplication, without adding to much overhead in my opinion (an empty list test when signaling the objects). Looking at the code again, this really makes sense, go for it. Out of curiosity: Did you already have a chance to compare a multi-threaded demo application with one based on these new select services? I guess your current test cases are built on top of RTnet, aren't they? Would be nice, also for regression testing, to have some demo for /examples, e.g. exploiting the CAN stack (because it has virtual CAN, thus it is usable without hardware). Ok, I had a look at the CAN stack, if I understand correctly when receiving, the recv_sem defined in rcan_socket.h is used, and when sending, the tx_sem defined in rtcan_dev.h is used. Can you confirm this ? Yep, that's correct. rx_sem counts received packets, tx_sem the number of available output slots in the CAN port. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 0/5] Support for select v2.
Gilles Chanteperdrix wrote: Hi, after some tests, bug fixes and optimizations, here comes a second version of the patch-set adding select support to xenomai posix skin. Puh, a lot of code, and my brain is still full of KGDB stuff I'm trying to polish for mainline since days. The approach looks consistent to me. I would just suggest to make the whole thing configurable, so that it doesn't add overhead to systems which do not use it. Out of curiosity: Did you already have a chance to compare a multi-threaded demo application with one based on these new select services? I guess your current test cases are built on top of RTnet, aren't they? Would be nice, also for regression testing, to have some demo for /examples, e.g. exploiting the CAN stack (because it has virtual CAN, thus it is usable without hardware). Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 0/5] Support for select v2.
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Hi, after some tests, bug fixes and optimizations, here comes a second version of the patch-set adding select support to xenomai posix skin. Puh, a lot of code, and my brain is still full of KGDB stuff I'm trying to polish for mainline since days. The approach looks consistent to me. I would just suggest to make the whole thing configurable, so that it doesn't add overhead to systems which do not use it. The core support does not take that much code. The RTDM patch however is huge, that is because we duplicate each rtdm_event and rtdm_sem service for the select-enabled objects. What would you think of adding select support to the rtdm_event and rtdm_sem objects without creating the new rtdm_select_event_t and rtdm_select_sem_t objects if the whole select support was configurable ? That is if select support is not selected, RTDM is as before, if select is enabled, rtdm_event_t and rtdm_sem_t objects may be used with select. Out of curiosity: Did you already have a chance to compare a multi-threaded demo application with one based on these new select services? We compared two standard Linux applications, one using select, the other being threaded, and there is no question: the select based scales much better. But as usual, it was on low end ARM hardware. I guess your current test cases are built on top of RTnet, aren't they? Would be nice, also for regression testing, to have some demo for /examples, e.g. exploiting the CAN stack (because it has virtual CAN, thus it is usable without hardware). Ok, will probably do that. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 0/5] Support for select v2.
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi,
after some tests, bug fixes and optimizations, here comes a second version
of
the patch-set adding select support to xenomai posix skin.
It's on my agenda for today or tomorrow to have a closer look at this.
Just one general question already: Why is it select and not poll and
select? Is it trivial to extend later on?
The patch I sent for adding select support to RTnet sockets was
uselessly complicated. Here is a simpler one.
--
Gilles Chanteperdrix.
Index: stack/ipv4/af_inet.c
===
--- stack/ipv4/af_inet.c(révision 6193)
+++ stack/ipv4/af_inet.c(copie de travail)
@@ -294,6 +294,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,7 @@ struct rtsocket {
unsigned intpriority;
nanosecs_rel_t timeout;/* receive timeout, 0 for infinite */
-rtdm_sem_t pending_sem;
+rtdm_select_sem_t pending_sem;
#ifdef CONFIG_RTNET_RTDM_SELECT
wait_queue_primitive_t *wakeup_select; /* for selecting calls - this
SHOULD be the head of a wait
@@ -96,6 +96,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)
@@ -87,7 +87,25 @@ 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:
+case XNSELECT_EXCEPT:
+ return -EBADF;
+}
+return -EINVAL;
+}
+EXPORT_SYMBOL(rt_socket_select_bind);
/***
* rt_socket_cleanup - releases resources allocated for the socket
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
